API:n p99-latenssi on 3s — miten debuggaat ja optimoit sen?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: hitain 1 % pyynnöistä kestää 3s. Ensimmäinen siirto on **mitata ja pilkkoa, ei arvata**. Vertaa p50:tä ja p99:ää — jos p50 on nopea mutta p99 on 3s, polku ei ole tasaisesti hidas; jokin puree vain *kuormituksen alla tai reunatapauksissa* (pool saturation, GC-tauot, N+1, cold cache, ajastamaton ulkoinen kutsu).

**Ajatusmalli:** p99 on *pisin kassajono*, ei keskimääräinen odotus — keskiarvon nopeuttaminen ei tee mitään takana jumissa olevalle asiakkaalle.

## Prosessi (mistä mihin)
1. **Mittaa & pilko** — RED-metriikat (Rate, Errors, Duration) + distributed tracing; lue p50/p95/p99. Niiden välinen *ero* kertoo tarinan.
2. **Paikanna vaihe** — instrumentoi jokainen askel nähdäksesi, missä hitaat pyynnöt viettävät aikaa; älä optimoi mutu-tuntumalta.

```js
// Ajasta jokainen vaihe nähdäksesi missä p99 kasautuu (älä arvaa)
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'); // epäilty
  res.json(courses);                         mark('total');
}
```

3. **Tunnista tail-epäilty** — yleensä *odottamista*, ei laskentaa: connection-pool exhaustion, N+1-kyselyt, ajastamattomat ulkoiset kutsut, GC-tauot, puuttuva indeksi, cold cache.

```js
// ENNEN: N+1 — N peräkkäistä round-trippiä, p99 räjähtää kun N kasvaa
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// JÄLKEEN: tiivistä 1 kyselyyn -> tail putoaa (ei enää N peräkkäistä trippiä)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // yksi IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Tässä p50 (pieni N) näyttää hyvältä, mutta kuormituksen alla N kasvaa ja pool saturoituu, joten **p99 detonoi**. Ulkoisille kutsuille aseta aina **timeout + circuit breaker**, jottei yksi hidas riippuvuus voi vetää koko endpointin p99:ää alas.

4. **Korjaa yksi asia → mittaa p99 uudelleen → toista.** Yksi muuttuja kerrallaan, tai et tiedä mikä auttoi.
5. **Lukitse se** — aseta **SLO** (esim. p99 < 300ms) + alert, jottei se regressoi.

## Haastattelunäkökulma
Haastattelija tunnustelee *metodista* prosessia, ei onnekasta arvausta: erotatko **tailin keskiarvosta**, mittaatko ennen muutosta, ja katsotko **jonoja/lukkoja (odottamista) ennen CPU:ta**. Heikko vastaus: "lisää caching / skaalaa serverit ylös." Vahva vastaus: mittaa → paikanna tracingilla → korjaa spesifi tail-syy → varmista numeroilla.

## Periaate
Optimoi **tail (p99), ei keskiarvo**. Suurin osa "3s p99":stä tulee *odottamisesta* (pool/queue/lock) eikä *laskennasta* — joten katso jonoja ennen CPU:ta.

Prosessi (mistä mihin)

Haastattelunäkökulma

Periaate

Aiheeseen liittyvät kysymykset