- Shipped
- 6 listopada 2026 18:31 UTC
- Author
- Kamo
- Commit
- 5b273d8
Wynik prasy podłogi, profilowane z JFR na SecurityService pod (lab org, 40 prasy): Zapis /stage trwał 160-360 ms, mediana ~220 ms, z czego około 90 ms to czas po zatwierdzeniu Nikt nie czeka: tracker kontaktów (etykieta statusu odczytana + 2-3 upserty, każdy z własnym YugabyteDB) Usługa, która deklaruje nowy potok (np. commit) i naśladowcę potoku (drugie pełne obciążenie Lead) LeadStatusFollowUps wykonawca teraz odpowiada, gdy status został zobowiązany i uruchamia te dwa na nim; Bez niego działają one w linii jak wcześniej. Stop All Outreach i due-callback Synchroniczne. Planer YugabyteDB jest heurystyczny: "org_id = ? AND <key>" przechodzi przez indeks organizacji Największa organizacja (EXPLAIN ANALYZE, tylko do odczytu): - historia leadów według leadów: 17.9 s -> 35 ms. Odczyty per-lead przechodzą przez lead_uid, org sprawdzane przez key. - DialLedger odczyt pierwszego tekstu: 7,15 s -> ~1,5 ms (tylko uid, org sprawdzane w Javie). - **************** tylko przez uid, org sprawdzane w Javie (dostęp do nagrywania, etykiety). - /leads grid z nazwanymi leadami (Wybrana zakładka, strumień leadów): org check written org_id + 0 = ?, 7.06 s -> 4.6 ms; ten sam filtr, żaden indeks nie może go obsłużyć, więc używany jest pk.