- Verschickt
- 6. November 2026 um 18:31 UTC
- Autor
- Kamo
- Commit
- 5b273d8
Floor-Ergebnispresse, profiliert mit JFR auf einem SecurityService-Pod (Lab-Org, 40 Pressen): die /stage write dauerte 160-360 ms, median ~220 ms. Etwa 90 ms davon waren die Follow-ups nach dem Commit Niemand wartet: der Kontakt-Tracker (Status-Label gelesen + 2-3 Upsets, jeweils ein eigenes YugabyteDB Ein Dienst, der die neue Pipeline deklariert, wird als Pipeline-Follower bezeichnet Der LeadStatusFollowUps-Executor antwortet nun, sobald der Status bestätigt wurde, und führt diese beiden darauf aus; Ohne einen laufen sie wie zuvor inline. Stop All Outreach und der due-callback close stay Synchron. Der Planer von YugabyteDB ist heuristisch: "org_id = ? AND <key>" durchläuft den Index der Organisation Die größte Organisation (EXPLAIN ANALYZE, schreibgeschützt): - Lead-Historie pro Lead: 17.9 s -> 35 ms. Die pro-Lead-Lese gehen nach lead_uid, org überprüft durch Schlüssel. - DialLedger erste Textleitung lesen: 7,15 s -> ~1,5 ms (nur UID, org in Java geprüft). - **************** durch uid nur, org in Java geprüft (Aufzeichnungszugriff, Labels). - /leads grid mit benannten Leads (Ausgewählte Registerkarte, Stream-Leads): org check written org_id + 0 = ?, 7.06 s -> 4.6 ms; gleicher Filter, kein Index kann es bedienen, also wird der pk verwendet.