p99 latencija nekog API-ja je 3s — kako to debugiraš i optimiziraš?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: najsporijih 1% zahtjeva traje 3s. Prvi potez je **izmjeriti i raščlaniti, ne nagađati**. Usporedi p50 i p99 — ako je p50 brz ali p99 je 3s, put nije ravnomjerno spor; nešto ugriza samo *pod opterećenjem ili u rubnim slučajevima* (zasićenje poola, GC pauze, N+1, hladni cache, netimeirani vanjski poziv).

**Mentalni model:** p99 je *najduži red na blagajni*, ne prosječno čekanje — ubrzavanje prosjeka ne čini ništa za kupca zaglavljenog na kraju.

## Proces (od početka do kraja)
1. **Izmjeri i raščlani** — RED metrike (Rate, Errors, Duration) + distributed tracing; čitaj p50/p95/p99. *Razmak* među njima priča priču.
2. **Lokaliziraj fazu** — instrumentiraj svaki korak da vidiš gdje spori zahtjevi troše vrijeme; ne optimiziraj po osjećaju.

```js
// Izmjeri svaku fazu da vidiš gdje se p99 gomila (ne nagađaj)
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'); // sumnjivo
  res.json(courses);                         mark('total');
}
```

3. **Identificiraj sumnjivca u repu** — obično je *čekanje*, ne računanje: iscrpljenje connection-poola, N+1 upiti, netimeirani vanjski pozivi, GC pauze, nedostajući indeks, hladni cache.

```js
// PRIJE: N+1 — N sekvencijalnih obilazaka, p99 eksplodira kako N raste
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// POSLIJE: sažmi na 1 upit -> rep pada (nema više N sekvencijalnih obilazaka)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // jedan IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Ovdje p50 (mali N) izgleda dobro, ali pod opterećenjem N raste i pool se zasiti, pa **p99 detonira**. Za vanjske pozive uvijek postavi **timeout + circuit breaker** da jedna spora ovisnost ne može povući p99 cijelog endpointa.

4. **Popravi jednu stvar → ponovno izmjeri p99 → ponovi.** Jedna varijabla odjednom, inače nećeš znati što je pomoglo.
5. **Učvrsti to** — postavi **SLO** (npr. p99 < 300ms) + alert da ne regresira.

## Kroz oči intervjua
Ispitivač propituje *metodičan* proces, ne sretno pogađanje: razlikuješ li **rep od srednje vrijednosti**, mjeriš li prije mijenjanja i gledaš li **redove/zaključavanja (čekanje) prije CPU-a**. Slab odgovor: "dodaj caching / skaliraj servere." Jak odgovor: izmjeri → lokaliziraj tracingom → popravi specifičan uzrok repa → provjeri brojkama.

## Načelo
Optimiziraj **rep (p99), ne prosjek.** Većina "3s p99" dolazi od *čekanja* (pool/red/zaključavanje) prije nego od *računanja* — pa gledaj redove prije CPU-a.

Proces (od početka do kraja)

Kroz oči intervjua

Načelo

Povezana pitanja