Et API's p99-latency er 3s — hvordan debugger og optimerer du den?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: de langsomste 1% af requests tager 3s. Det første træk er at **måle og bryde det ned, ikke gætte**. Sammenlign p50 vs p99 — hvis p50 er hurtig men p99 er 3s, er stien ikke ensartet langsom; noget bider kun *under load eller i edge cases* (pool-mætning, GC-pauser, N+1, cold cache, et un-timet eksternt kald).

**Mental model:** p99 er den *længste kø ved kassen*, ikke den gennemsnitlige ventetid — at gøre gennemsnittet hurtigere gør intet for kunden, der sidder fast bagerst.

## Processen (fra hvor til hvor)
1. **Mål & bryd ned** — RED-metrics (Rate, Errors, Duration) + distributed tracing; læs p50/p95/p99. *Gabet* mellem dem fortæller historien.
2. **Lokalisér stadiet** — instrumentér hvert trin for at se hvor langsomme requests bruger tid; optimér ikke på en fornemmelse.

```js
// Tag tid på hvert stadie for at se hvor p99 hober sig op (gæt ikke)
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'); // mistænkt
  res.json(courses);                         mark('total');
}
```

3. **Identificér tail-mistænkte** — som regel *venten*, ikke computing: connection-pool-udtømning, N+1-queries, un-timede eksterne kald, GC-pauser, manglende index, cold cache.

```js
// FØR: N+1 — N sekventielle round-trips, p99 eksploderer når N vokser
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// EFTER: kollaps til 1 query -> tail'en falder (ikke flere N sekventielle trips)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // ét IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Her ser p50 (lille N) fin ud, men under load vokser N og pool'en mættes, så **p99 detonerer**. For eksterne kald, sæt altid en **timeout + circuit breaker** så én langsom dependency ikke kan trække hele endpointets p99 ned.

4. **Fix én ting → mål p99 igen → gentag.** Én variabel ad gangen, ellers ved du ikke hvad der hjalp.
5. **Lås det fast** — sæt et **SLO** (fx p99 < 300ms) + alert så det ikke regredierer.

## Interview lens
Intervieweren undersøger en *metodisk* proces, ikke et heldigt gæt: skelner du **tail fra mean**, måler du før du ændrer, og kigger du på **køer/locks (venten) før CPU**. Svagt svar: "tilføj caching / skalér serverne op." Stærkt svar: mål → lokalisér med tracing → fix den specifikke tail-årsag → verificér med tal.

## Princip
Optimér **tail'en (p99), ikke gennemsnittet**. De fleste "3s p99" kommer fra *venten* (pool/kø/lock) snarere end *computing* — så kig på køer før CPU.

Processen (fra hvor til hvor)

Interview lens

Princip

Relaterede spørgsmål