एक API का p99 latency 3s है — आप इसे कैसे debug और optimize करेंगे?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: सबसे धीमे 1% requests को 3s लगते हैं। पहला कदम है **मापें और उसे तोड़कर देखें, अनुमान न लगाएँ**। p50 बनाम p99 की तुलना करें — अगर p50 तेज़ है पर p99 3s है, तो path समान रूप से धीमा नहीं है; कुछ केवल *load में या edge cases में* काटता है (pool saturation, GC pauses, N+1, cold cache, बिना time किया गया external call)।

**मानसिक मॉडल:** p99 *सबसे लंबी checkout लाइन* है, औसत प्रतीक्षा नहीं — औसत को तेज़ करने से पीछे फँसे ग्राहक को कोई फ़र्क नहीं पड़ता।

## प्रक्रिया (कहाँ से कहाँ तक)
1. **मापें और तोड़ें** — RED metrics (Rate, Errors, Duration) + distributed tracing; p50/p95/p99 पढ़ें। इनके बीच का *अंतर* कहानी बताता है।
2. **stage को localize करें** — हर step को instrument करें ताकि दिखे कि धीमे requests कहाँ समय बिताते हैं; अनुमान पर optimize न करें।

```js
// हर stage को time करें ताकि पता चले p99 कहाँ जमा होता है (अनुमान न लगाएँ)
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'); // संदिग्ध
  res.json(courses);                         mark('total');
}
```

3. **tail के संदिग्ध को पहचानें** — आमतौर पर *इंतज़ार*, गणना नहीं: connection-pool exhaustion, N+1 queries, बिना time किए external calls, GC pauses, missing index, cold cache।

```js
// BEFORE: N+1 — N sequential round-trips, N बढ़ने पर p99 फट जाता है
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// AFTER: 1 query में समेटें -> tail गिरता है (अब N sequential trips नहीं)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // एक IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

यहाँ p50 (छोटा N) ठीक दिखता है, पर load में N बढ़ता है और pool saturate होता है, इसलिए **p99 फट जाता है**। external calls के लिए हमेशा एक **timeout + circuit breaker** सेट करें ताकि एक धीमी dependency पूरे endpoint के p99 को न खींचे।

4. **एक चीज़ ठीक करें → p99 दोबारा मापें → दोहराएँ।** एक बार में एक variable, वरना पता नहीं चलेगा कि किसने मदद की।
5. **इसे पक्का करें** — एक **SLO** सेट करें (जैसे p99 < 300ms) + alert ताकि regress न हो।

## इंटरव्यू का नज़रिया
इंटरव्यूअर एक *व्यवस्थित* प्रक्रिया परख रहा है, भाग्यशाली अनुमान नहीं: क्या आप **tail को mean से** अलग करते हैं, बदलने से पहले मापते हैं, और **CPU से पहले queues/locks (इंतज़ार)** देखते हैं। कमज़ोर जवाब: "caching जोड़ो / servers scale up करो।" मज़बूत जवाब: मापें → tracing से localize करें → विशिष्ट tail कारण ठीक करें → संख्याओं से verify करें।

## सिद्धांत
**tail (p99) को optimize करें, औसत को नहीं।** अधिकांश "3s p99" *गणना* के बजाय *इंतज़ार* (pool/queue/lock) से आता है — इसलिए CPU से पहले queues देखें।

प्रक्रिया (कहाँ से कहाँ तक)

इंटरव्यू का नज़रिया

सिद्धांत

संबंधित प्रश्न