Die p99-Latenz einer API beträgt 3s — wie debuggst und optimierst du sie?

Question

IT Interview Practice · Accepted Answer

p99 = **Tail Latency**: Das langsamste 1 % der Requests braucht 3s. Der erste Zug ist, zu **messen und aufzuschlüsseln, nicht zu raten**. Vergleiche p50 vs. p99 — wenn p50 schnell ist, aber p99 bei 3s liegt, ist der Pfad nicht gleichmäßig langsam; etwas beißt nur *unter Last oder in Edge Cases* zu (Pool-Sättigung, GC-Pausen, N+1, kalter Cache, ein ungetimeter externer Call).

**Mentales Modell:** p99 ist die *längste Kassenschlange*, nicht die durchschnittliche Wartezeit — den Durchschnitt zu beschleunigen bringt dem Kunden, der ganz hinten feststeckt, gar nichts.

## Der Prozess (von wo nach wo)
1. **Messen & aufschlüsseln** — RED-Metriken (Rate, Errors, Duration) + Distributed Tracing; lies p50/p95/p99. Der *Abstand* zwischen ihnen erzählt die Geschichte.
2. **Die Stufe lokalisieren** — instrumentiere jeden Schritt, um zu sehen, wo langsame Requests ihre Zeit verbringen; optimiere nicht nach Bauchgefühl.

```js
// Jede Stufe messen, um zu sehen, wo sich p99 auftürmt (nicht raten)
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'); // verdächtig
  res.json(courses);                         mark('total');
}
```

3. **Den Tail-Verdächtigen identifizieren** — meist *Warten*, nicht Rechnen: Connection-Pool-Erschöpfung, N+1-Queries, ungetimete externe Calls, GC-Pausen, fehlender Index, kalter Cache.

```js
// VORHER: N+1 — N sequenzielle Round-Trips, p99 explodiert, wenn N wächst
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// NACHHER: auf 1 Query zusammenfassen -> der Tail fällt (keine N sequenziellen Trips mehr)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // ein IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Hier sieht p50 (kleines N) gut aus, aber unter Last wächst N und der Pool sättigt, sodass **p99 detoniert**. Setze für externe Calls immer einen **Timeout + Circuit Breaker**, damit eine langsame Dependency nicht die p99 des gesamten Endpoints herunterziehen kann.

4. **Eine Sache fixen → p99 erneut messen → wiederholen.** Eine Variable nach der anderen, sonst weißt du nicht, was geholfen hat.
5. **Festzurren** — setze ein **SLO** (z. B. p99 < 300ms) + Alert, damit es nicht regrediert.

## Interview-Perspektive
Der Interviewer prüft einen *methodischen* Prozess, keine Glücksraterei: Unterscheidest du **Tail von Mittelwert**, misst du, bevor du änderst, und schaust du auf **Queues/Locks (Warten) vor CPU**. Schwache Antwort: "Caching hinzufügen / die Server hochskalieren." Starke Antwort: messen → mit Tracing lokalisieren → die spezifische Tail-Ursache fixen → mit Zahlen verifizieren.

## Prinzip
Optimiere den **Tail (p99), nicht den Durchschnitt**. Die meisten "3s p99" kommen von *Warten* (Pool/Queue/Lock) statt von *Rechnen* — schau also auf Queues vor CPU.

Der Prozess (von wo nach wo)

Interview-Perspektive

Prinzip

Ähnliche Fragen