- Expédié
- 6 novembre 2026 à 18:31 UTC
- Auteur
- Kamo
- Commit
- 5b273d8
Appeler Presse de résultat de plancher, profilé avec JFR sur un pod SecurityService (lab org, 40 presses): le L'écriture de /stage a pris 160-360 ms, la médiane ~220 ms, dont environ 90 ms pour les suivis post-commit Personne n'attend: le suivi des contacts (étiquette de statut lue + 2-3 upserts, chacune avec son propre YugabyteDB Un service qui déclare le nouveau pipeline (commit) et le suivi du pipeline (une deuxième charge complète de Lead) L'exécuteur LeadStatusFollowUps répond maintenant une fois que l'état a été validé et exécute ces deux sur celui-ci; Sans un, ils s'exécutent en ligne comme auparavant. Stop All Outreach synchrone. Le planificateur de YugabyteDB est heuristique: "org_id = ? AND <key>" parcourt l'index de l'organisation largest org (EXPLAIN ANALYZE, lecture seule): - historique des leads par lead: 17.9 s -> 35 ms. Les lectures par lead vont par lead_uid, org vérifié par clé. - DialLedger premier-texte lead lu: 7.15 s -> ~1.5 ms (uid seulement, org vérifié en Java). - **************** par uid uniquement, org vérifié en Java (accès d'enregistrement, labels). - /leads grille avec des leads nommés (onglet sélectionné, flux de leads): org check written org_id + 0 = ?, 7.06 s -> 4.6 ms; même filtre, aucun index ne peut le servir, donc le pk est utilisé.