Et API-s p99-latency er 3s — hvordan debugger og optimaliserer du det?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: de tregeste 1 % av requests bruker 3s. Det første trekket er å **måle og bryte det ned, ikke gjette**. Sammenlign p50 mot p99 — hvis p50 er rask, men p99 er 3s, er ikke veien jevnt treg; noe biter kun *under load eller i edge cases* (pool-metning, GC-pauser, N+1, kald cache, et utimet eksternt kall).

**Mental modell:** p99 er den *lengste kassakøen*, ikke gjennomsnittsventetiden — å gjøre gjennomsnittet raskere gjør ingenting for kunden som står fast bakerst.

## Prosessen (fra hvor til hvor)
1. **Mål & bryt ned** — RED-metrikker (Rate, Errors, Duration) + distribuert tracing; les p50/p95/p99. *Gapet* mellom dem forteller historien.
2. **Lokaliser stadiet** — instrumenter hvert steg for å se hvor trege requests bruker tid; ikke optimaliser på en anelse.

```js
// Ta tiden på hvert stadium for å se hvor p99 hoper seg opp (ikke gjett)
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'); // mistenkt
  res.json(courses);                         mark('total');
}
```

3. **Identifiser tail-mistenkten** — vanligvis *venting*, ikke computing: connection-pool-uttømming, N+1-queries, utimede eksterne kall, GC-pauser, manglende indeks, kald cache.

```js
// FØR: N+1 — N sekvensielle round-trips, p99 eksploderer når N vokser
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// ETTER: kollaps til 1 query -> tailen faller (ingen flere N sekvensielle trips)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // én IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Her ser p50 (liten N) fin ut, men under load vokser N og poolen metter, så **p99 detonerer**. For eksterne kall, sett alltid en **timeout + circuit breaker** så én treg avhengighet ikke kan dra ned hele endepunktets p99.

4. **Fiks én ting → re-mål p99 → gjenta.** Én variabel om gangen, ellers vet du ikke hva som hjalp.
5. **Lås det inn** — sett en **SLO** (f.eks. p99 < 300ms) + alert så det ikke regredierer.

## Intervjuperspektiv
Intervjueren undersøker en *metodisk* prosess, ikke et heldig gjett: skiller du **tail fra mean**, måler du før du endrer, og ser du på **køer/låser (venting) før CPU**. Svakt svar: «legg til caching / skaler opp serverne.» Sterkt svar: mål → lokaliser med tracing → fiks den spesifikke tail-årsaken → verifiser med tall.

## Prinsipp
Optimaliser **tailen (p99), ikke gjennomsnittet**. De fleste «3s p99» kommer fra *venting* (pool/kø/lås) heller enn *computing* — så se på køer før CPU.

Prosessen (fra hvor til hvor)

Intervjuperspektiv

Prinsipp

Relaterte spørsmål