p99 latenca API-ja je 3s — kako jo razhroščite in optimizirate?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: najpočasnejši 1 % zahtevkov traja 3s. Prva poteza je **izmeriti in razčleniti, ne ugibati**. Primerjaj p50 proti p99 — če je p50 hiter, p99 pa 3s, pot ni enakomerno počasna; nekaj ugrizne le *pod obremenitvijo ali v robnih primerih* (nasičenost pool-a, GC premori, N+1, hladen cache, nemeren zunanji klic).

**Miselni model:** p99 je *najdaljša vrsta na blagajni*, ne povprečno čakanje — pospešitev povprečja ne naredi nič za kupca, ki obtiči na koncu.

## Postopek (od kod do kam)
1. **Izmeri in razčleni** — RED metrike (Rate, Errors, Duration) + distributed tracing; preberi p50/p95/p99. *Razlika* med njimi pove zgodbo.
2. **Lokaliziraj stopnjo** — instrumentiraj vsak korak, da vidiš, kje počasni zahtevki porabijo čas; ne optimiziraj po občutku.

```js
// Meri vsako stopnjo, da vidiš, kje se kopiči p99 (ne ugibaj)
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'); // osumljenec
  res.json(courses);                         mark('total');
}
```

3. **Prepoznaj osumljenca repa** — običajno *čakanje*, ne računanje: izčrpanje connection pool-a, N+1 poizvedbe, nemereni zunanji klici, GC premori, manjkajoč indeks, hladen cache.

```js
// PREJ: N+1 — N zaporednih round-tripov, p99 eksplodira, ko N raste
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// POTEM: strni v 1 poizvedbo -> rep pade (nič več N zaporednih tripov)
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) ?? [];
```

Tukaj p50 (majhen N) izgleda v redu, a pod obremenitvijo N raste in se pool nasiti, zato **p99 detonira**. Za zunanje klice vedno nastavi **timeout + circuit breaker**, da ena počasna odvisnost ne more povleči p99 celotnega endpointa.

4. **Popravi eno stvar → ponovno izmeri p99 → ponovi.** Ena spremenljivka naenkrat, sicer ne boš vedel, kaj je pomagalo.
5. **Zaklep** — nastavi **SLO** (npr. p99 < 300ms) + alert, da ne regresira.

## Vidik intervjuja
Izpraševalec preverja *metodičen* postopek, ne srečno ugibanje: ali ločiš **rep od povprečja**, meriš pred spreminjanjem in gledaš **vrste/ključavnice (čakanje) pred CPU**. Šibek odgovor: "dodaj caching / poveča strežnike." Močan odgovor: izmeri → lokaliziraj s tracingom → popravi specifičen vzrok repa → preveri s številkami.

## Načelo
Optimiziraj **rep (p99), ne povprečja**. Večina "3s p99" prihaja iz *čakanja* (pool/vrsta/ključavnica) namesto iz *računanja* — zato glej vrste pred CPU.

Postopek (od kod do kam)

Vidik intervjuja

Načelo

Povezana vprašanja