p99 latency API wynosi 3 s — jak to debugujesz i optymalizujesz?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: najwolniejszy 1% requestów zajmuje 3 s. Pierwszy ruch to **zmierzyć i rozłożyć na części, nie zgadywać**. Porównaj p50 z p99 — jeśli p50 jest szybkie, ale p99 to 3 s, ścieżka nie jest równomiernie wolna; coś gryzie tylko *pod obciążeniem lub w przypadkach brzegowych* (saturacja pooli, pauzy GC, N+1, zimny cache, nieobmierzone wywołanie zewnętrzne).

**Model mentalny:** p99 to *najdłuższa kolejka do kasy*, a nie średni czas oczekiwania — przyspieszenie średniej nic nie daje klientowi utkniętemu na końcu.

## Proces (skąd dokąd)
1. **Zmierz i rozłóż** — metryki RED (Rate, Errors, Duration) + distributed tracing; odczytaj p50/p95/p99. To *odstęp* między nimi opowiada historię.
2. **Zlokalizuj etap** — oinstrumentuj każdy krok, aby zobaczyć, gdzie wolne requesty spędzają czas; nie optymalizuj na przeczucie.

```js
// Zmierz czas każdego etapu, aby zobaczyć, gdzie kumuluje się p99 (nie zgaduj)
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'); // podejrzany
  res.json(courses);                         mark('total');
}
```

3. **Wskaż podejrzanego z ogona** — zwykle *czekanie*, nie liczenie: wyczerpanie connection pool, zapytania N+1, nieobmierzone wywołania zewnętrzne, pauzy GC, brak indeksu, zimny cache.

```js
// PRZED: N+1 — N sekwencyjnych round-tripów, p99 wybucha wraz ze wzrostem N
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// PO: zwiń do 1 zapytania -> ogon spada (koniec z N sekwencyjnymi podróżami)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // jedno IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Tutaj p50 (małe N) wygląda w porządku, ale pod obciążeniem N rośnie i pool się saturuje, więc **p99 detonuje**. Dla wywołań zewnętrznych zawsze ustaw **timeout + circuit breaker**, aby jedna wolna zależność nie mogła pociągnąć w dół p99 całego endpointa.

4. **Napraw jedną rzecz → zmierz p99 ponownie → powtórz.** Jedna zmienna naraz, inaczej nie będziesz wiedzieć, co pomogło.
5. **Utrwal to** — ustaw **SLO** (np. p99 < 300 ms) + alert, aby nie było regresji.

## Perspektywa rozmowy
Prowadzący sprawdza *metodyczny* proces, a nie szczęśliwe zgadywanie: czy odróżniasz **ogon od średniej**, mierzysz przed zmianą i patrzysz na **kolejki/blokady (czekanie) przed CPU**. Słaba odpowiedź: „dodaj cache / dołóż serwerów”. Mocna odpowiedź: zmierz → zlokalizuj tracingiem → napraw konkretną przyczynę ogona → zweryfikuj liczbami.

## Zasada
Optymalizuj **ogon (p99), nie średnią**. Większość „p99 = 3 s” bierze się z *czekania* (pool/kolejka/blokada), a nie z *liczenia* — więc patrz na kolejki przed CPU.

Proces (skąd dokąd)

Perspektywa rozmowy

Zasada

Powiązane pytania