- Enviado
- 6 de noviembre de 2026 a las 18:31 UTC
- Autor
- Kamo
- Commit
- 5b273d8
Llamada Prensa de resultado de piso, perfilado con JFR en un pod de SecurityService (lab org, 40 prensas): el /stage write tomó 160-360 ms, mediana ~220 ms. Aproximadamente 90 ms de esto fue el seguimiento post-commit Nadie espera: el rastreador de contactos (etiqueta de estado leída + 2-3 upserts, cada uno con su propio YugabyteDB Un servicio que declara el nuevo canal (commit) y el seguidor de la canalización (una segunda carga completa de Lead) El ejecutor de LeadStatusFollowUps ahora responde una vez que el estado se ha comprometido y ejecuta esos dos en él; Sin uno, se ejecutan en línea como antes. Detener todo el alcance y el cierre de devolución de llamada synchronous. El planificador de YugabyteDB es heurístico: "org_id = ? AND <key>" recorre el índice de la organización largest org (EXPLAIN ANALYZE, solo lectura): - historial de leads por lead: 17.9 s -> 35 ms. Las lecturas por lead van por lead_uid, org comprobado por clave. - DialLedger primera lectura de texto: 7,15 s -> ~ 1,5 ms (uid solo, org comprobado en Java). - **************** por uid solamente, org verificado en Java (acceso de grabación, etiquetas). - /leads cuadrícula con los clientes potenciales con nombre (pestaña seleccionada, flujo de clientes potenciales): org check escrito org_id + 0 = ?, 7.06 s -> 4.6 ms; mismo filtro, ningún índice puede servirlo, por lo que se usa el pk.