De p99-latency van een API is 3s — hoe debug en optimaliseer je dit?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: de traagste 1% van de requests duurt 3s. De eerste zet is om **te meten en op te splitsen, niet te gokken**. Vergelijk p50 met p99 — als p50 snel is maar p99 3s is, is het pad niet uniform traag; iets bijt alleen *onder belasting of in edge cases* (pool-verzadiging, GC-pauzes, N+1, cold cache, een niet-getimede externe call).

**Mentaal model:** p99 is de *langste kassarij*, niet de gemiddelde wachttijd — het gemiddelde versnellen doet niets voor de klant die achteraan vastzit.

## Het proces (van waar naar waar)
1. **Meten & opsplitsen** — RED-metrics (Rate, Errors, Duration) + distributed tracing; lees p50/p95/p99. De *kloof* daartussen vertelt het verhaal.
2. **Lokaliseer de fase** — instrumenteer elke stap om te zien waar trage requests hun tijd besteden; optimaliseer niet op een onderbuikgevoel.

```js
// Time elke fase om te zien waar p99 zich opstapelt (niet gokken)
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'); // verdachte
  res.json(courses);                         mark('total');
}
```

3. **Identificeer de tail-verdachte** — meestal *wachten*, niet rekenen: uitputting van de connection pool, N+1 queries, niet-getimede externe calls, GC-pauzes, ontbrekende index, cold cache.

```js
// VOOR: N+1 — N sequentiële round-trips, p99 explodeert naarmate N groeit
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// NA: reduceer tot 1 query -> de tail daalt (geen N sequentiële trips meer)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // one IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Hier ziet p50 (kleine N) er prima uit, maar onder belasting groeit N en verzadigt de pool, dus **p99 detoneert**. Zet voor externe calls altijd een **timeout + circuit breaker** zodat één trage dependency de p99 van het hele endpoint niet kan meesleuren.

4. **Fix één ding → meet p99 opnieuw → herhaal.** Eén variabele per keer, anders weet je niet wat hielp.
5. **Leg het vast** — stel een **SLO** in (bijv. p99 < 300ms) + alert zodat het niet terugvalt.

## Interview-lens
De interviewer peilt een *methodisch* proces, geen gelukkige gok: onderscheid je **tail van gemiddelde**, meet je voordat je iets wijzigt, en kijk je naar **queues/locks (wachten) vóór CPU**. Zwak antwoord: "voeg caching toe / schaal de servers op." Sterk antwoord: meten → lokaliseren met tracing → de specifieke tail-oorzaak fixen → verifiëren met cijfers.

## Principe
Optimaliseer de **tail (p99), niet het gemiddelde**. Het meeste "3s p99" komt van *wachten* (pool/queue/lock) in plaats van *rekenen* — kijk dus naar queues vóór CPU.

Het proces (van waar naar waar)

Interview-lens

Principe

Gerelateerde vragen