p99 latence API je 3 s — jak to debuguješ a optimalizuješ?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: nejpomalejší 1 % požadavků trvá 3 s. Prvním tahem je **měřit a rozložit, ne hádat**. Porovnej p50 vs p99 — pokud je p50 rychlé, ale p99 je 3 s, cesta není rovnoměrně pomalá; něco kouše jen *pod zátěží nebo v okrajových případech* (saturace poolu, GC pauzy, N+1, studená cache, netimeoutovaný externí call).

**Mentální model:** p99 je *nejdelší fronta u pokladny*, ne průměrné čekání — zrychlení průměru neudělá nic pro zákazníka uvízlého vzadu.

## Postup (odkud kam)
1. **Změř a rozlož** — RED metriky (Rate, Errors, Duration) + distribuované tracing; čti p50/p95/p99. Příběh vypráví *mezera* mezi nimi.
2. **Lokalizuj fázi** — instrumentuj každý krok, abys viděl, kde pomalé požadavky tráví čas; neoptimalizuj podle tušení.

```js
// Změř čas každé fáze, abys viděl, kde se p99 hromadí (nehádej)
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // podezřelý
  res.json(courses);                         mark('total');
}
```

3. **Identifikuj podezřelého z tailu** — obvykle *čekání*, ne výpočet: vyčerpání connection poolu, N+1 dotazy, netimeoutované externí cally, GC pauzy, chybějící index, studená cache.

```js
// PŘED: N+1 — N sekvenčních round-tripů, p99 vybuchuje s rostoucím N
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// PO: sbal do 1 dotazu -> tail klesne (žádných N sekvenčních tripů)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // jedno IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Zde p50 (malé N) vypadá dobře, ale pod zátěží N roste a pool se saturuje, takže **p99 detonuje**. U externích callů vždy nastav **timeout + circuit breaker**, aby jedna pomalá závislost nemohla táhnout p99 celého endpointu.

4. **Oprav jednu věc → znovu změř p99 → opakuj.** Jedna proměnná v čase, jinak nebudeš vědět, co pomohlo.
5. **Zafixuj to** — nastav **SLO** (např. p99 < 300 ms) + alert, aby to neregresovalo.

## Pohled tazatele
Tazatel zkoumá *metodický* postup, ne šťastné hádání: rozlišuješ **tail od průměru**, měříš před změnou a díváš se na **fronty/zámky (čekání) před CPU**. Slabá odpověď: „přidej cachování / naškáluj servery." Silná odpověď: změř → lokalizuj tracingem → oprav konkrétní příčinu tailu → ověř čísly.

## Princip
Optimalizuj **tail (p99), ne průměr**. Většina „3s p99" pochází z *čekání* (pool/fronta/zámek) spíš než z *výpočtu* — takže se dívej na fronty před CPU.

Postup (odkud kam)

Pohled tazatele

Princip

Související otázky