Bir API'nin p99 gecikmesi 3 saniye — bunu nasıl debug eder ve optimize edersiniz?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: en yavaş %1'lik istekler 3 saniye sürer. İlk hamle **tahmin etmek değil, ölçmek ve parçalara ayırmaktır**. p50 ile p99'u karşılaştırın — p50 hızlı ama p99 3 saniyeyse, yol tek tip yavaş değildir; bir şey yalnızca *yük altında veya uç durumlarda* ısırıyor (pool doygunluğu, GC duraklamaları, N+1, soğuk cache, süresi ölçülmemiş harici bir çağrı).

**Zihinsel model:** p99 *en uzun kasa kuyruğudur*, ortalama bekleme değil — ortalamayı hızlandırmak, en arkada sıkışan müşteri için hiçbir şey yapmaz.

## Süreç (nereden nereye)
1. **Ölç & parçala** — RED metrikleri (Rate, Errors, Duration) + distributed tracing; p50/p95/p99'u oku. Aralarındaki *fark* hikayeyi anlatır.
2. **Aşamayı yerelleştir** — yavaş isteklerin zamanı nerede geçirdiğini görmek için her adımı enstrümante et; bir tahminle optimize etme.

```js
// p99'un nerede biriktiğini görmek için her aşamayı zamanla (tahmin etme)
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'); // şüpheli
  res.json(courses);                         mark('total');
}
```

3. **Kuyruğun (tail) şüphelisini belirle** — genellikle hesaplama değil *bekleme*: connection-pool tükenmesi, N+1 sorguları, süresi ölçülmemiş harici çağrılar, GC duraklamaları, eksik index, soğuk cache.

```js
// ÖNCE: N+1 — N ardışık gidiş-dönüş, N büyüdükçe p99 patlar
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// SONRA: 1 sorguya indirge -> tail düşer (artık N ardışık gidiş yok)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // tek IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Burada p50 (küçük N) iyi görünür, ama yük altında N büyür ve pool doyar, böylece **p99 patlar**. Harici çağrılar için, yavaş bir bağımlılığın tüm endpoint'in p99'unu aşağı çekememesi için her zaman bir **timeout + circuit breaker** ayarlayın.

4. **Bir şeyi düzelt → p99'u yeniden ölç → tekrarla.** Bir seferde bir değişken, yoksa neyin yardımcı olduğunu bilemezsiniz.
5. **Sabitle** — bir **SLO** ayarla (ör. p99 < 300ms) + alarm, böylece geriye gitmez.

## Mülakat merceği
Mülakatı yapan kişi şanslı bir tahmini değil, *metodik* bir süreci araştırıyor: **tail'i ortalamadan** ayırıyor musunuz, değiştirmeden önce ölçüyor musunuz ve CPU'dan önce **kuyruklara/kilitlere (bekleme)** bakıyor musunuz. Zayıf cevap: "caching ekle / sunucuları ölçekle." Güçlü cevap: ölç → tracing ile yerelleştir → belirli tail nedenini düzelt → sayılarla doğrula.

## İlke
**Ortalamayı değil, tail'i (p99)** optimize edin. Çoğu "3s p99", *hesaplamadan* ziyade *beklemeden* (pool/kuyruk/kilit) gelir — bu yüzden CPU'dan önce kuyruklara bakın.

Süreç (nereden nereye)

Mülakat merceği

İlke

İlgili sorular