En API:s p99-latens är 3 s — hur felsöker och optimerar du den?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: de långsammaste 1% av requests tar 3 s. Första draget är att **mäta och bryta ner, inte gissa**. Jämför p50 mot p99 — om p50 är snabb men p99 är 3 s är vägen inte enhetligt långsam; något biter bara *under last eller i edge cases* (pool-mättnad, GC-pauser, N+1, kall cache, ett otajmat externt anrop).

**Mental modell:** p99 är den *längsta kassakön*, inte den genomsnittliga väntetiden — att snabba upp genomsnittet gör inget för kunden som fastnat längst bak.

## Processen (från var till var)
1. **Mät & bryt ner** — RED-metrics (Rate, Errors, Duration) + distribuerad tracing; läs p50/p95/p99. *Gapet* mellan dem berättar historien.
2. **Lokalisera steget** — instrumentera varje steg för att se var långsamma requests spenderar tid; optimera inte på en aning.

```js
// Tajma varje steg för att se var p99 hopar sig (gissa inte)
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'); // misstänkt
  res.json(courses);                         mark('total');
}
```

3. **Identifiera tail-suspekten** — vanligtvis *väntande*, inte beräknande: connection-pool-uttömning, N+1-queries, otajmade externa anrop, GC-pauser, saknat index, kall cache.

```js
// FÖRE: N+1 — N sekventiella round-trips, p99 exploderar när N växer
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// EFTER: kollapsa till 1 query -> tail:en sjunker (inga fler N sekventiella resor)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // en IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Här ser p50 (litet N) bra ut, men under last växer N och poolen mättas, så **p99 detonerar**. För externa anrop, sätt alltid en **timeout + circuit breaker** så att ett långsamt beroende inte kan dra ner hela endpointens p99.

4. **Åtgärda en sak → mät p99 igen → upprepa.** En variabel i taget, annars vet du inte vad som hjälpte.
5. **Lås fast det** — sätt en **SLO** (t.ex. p99 < 300ms) + alert så att det inte regredierar.

## Intervjuperspektiv
Intervjuaren undersöker en *metodisk* process, inte en lyckträff: skiljer du **tail från medel**, mäter innan du ändrar, och tittar på **köer/lås (väntande) före CPU**. Svagt svar: "lägg till caching / skala upp servrarna." Starkt svar: mät → lokalisera med tracing → åtgärda den specifika tail-orsaken → verifiera med siffror.

## Princip
Optimera **tail (p99), inte genomsnittet**. Mest "3s p99" kommer från *väntande* (pool/kö/lås) snarare än *beräknande* — så titta på köer före CPU.

Processen (från var till var)

Intervjuperspektiv

Princip

Relaterade frågor