Egy API p99 latenciája 3s — hogyan debugolod és optimalizálod?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: a leglassabb 1% kérés 3 másodpercig tart. Az első lépés **mérni és lebontani, nem találgatni**. Hasonlítsd össze a p50-et a p99-cel — ha a p50 gyors, de a p99 3s, az útvonal nem egyenletesen lassú; valami csak *terhelés alatt vagy szélső esetekben* harap (pool telítődés, GC szünetek, N+1, hideg cache, időzítetlen külső hívás).

**Gondolati modell:** a p99 a *leghosszabb pénztári sor*, nem az átlagos várakozás — az átlag gyorsítása semmit sem tesz a hátul rekedt vevőért.

## A folyamat (honnan hová)
1. **Mérj és bonts le** — RED metrikák (Rate, Errors, Duration) + distributed tracing; olvasd a p50/p95/p99-et. A köztük lévő *rés* mesél.
2. **Lokalizáld a fázist** — műszerezz fel minden lépést, hogy lásd hol töltenek időt a lassú kérések; ne megérzésre optimalizálj.

```js
// Mérd meg minden fázist, hogy lásd hol torlódik a p99 (ne találgass)
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'); // gyanús
  res.json(courses);                         mark('total');
}
```

3. **Azonosítsd a farok gyanúsítottját** — általában *várakozás*, nem számítás: connection-pool kimerülés, N+1 lekérdezések, időzítetlen külső hívások, GC szünetek, hiányzó index, hideg cache.

```js
// ELŐTTE: N+1 — N szekvenciális körút, a p99 felrobban ahogy N nő
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// UTÁNA: 1 lekérdezéssé vonva -> a farok leesik (nincs több N szekvenciális körút)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // egy IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Itt a p50 (kis N) rendben néz ki, de terhelés alatt N nő és a pool telítődik, így **a p99 felrobban**. Külső hívásokhoz mindig állíts be **timeout + circuit breaker**-t, hogy egy lassú függőség ne húzhassa le az egész endpoint p99-ét.

4. **Javíts ki egy dolgot → mérd újra a p99-et → ismételd.** Egy változó egyszerre, különben nem tudod mi segített.
5. **Rögzítsd** — állíts be egy **SLO**-t (pl. p99 < 300ms) + riasztást, hogy ne romoljon vissza.

## Interjú szemszögéből
A kérdező *módszeres* folyamatot firtat, nem szerencsés találgatást: megkülönbözteted-e a **farkat az átlagtól**, mérsz-e a változtatás előtt, és nézed-e a **sorokat/zárakat (várakozás) a CPU előtt**. Gyenge válasz: "adj hozzá cache-t / skálázd fel a szervereket." Erős válasz: mérj → lokalizálj tracinggel → javítsd a konkrét farok-okot → ellenőrizd számokkal.

## Alapelv
A **farkat (p99) optimalizáld, ne az átlagot.** A legtöbb "3s p99" *várakozásból* (pool/sor/zár) ered, nem *számításból* — szóval a sorokat nézd a CPU előtt.

A folyamat (honnan hová)

Interjú szemszögéből

Alapelv

Kapcsolódó kérdések