એક API ની p99 latency 3s છે — તમે તેને કેવી રીતે debug અને optimize કરો છો?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: સૌથી ધીમા 1% requests 3s લે છે. પહેલી ચાલ છે **measure કરો અને break down કરો, guess નહીં**. p50 vs p99 ની સરખામણી કરો — જો p50 fast છે પણ p99 3s છે, તો path એકસરખો ધીમો નથી; કંઈક ફક્ત *load હેઠળ અથવા edge cases માં* કરડે છે (pool saturation, GC pauses, N+1, cold cache, એક un-timed external call).

**Mental model:** p99 એ *સૌથી લાંબી checkout line* છે, average wait નહીં — average ને ઝડપી કરવાથી પાછળ ફસાયેલા ગ્રાહક માટે કંઈ થતું નથી.

## The process (from where to where)
1. **Measure & break down** — RED metrics (Rate, Errors, Duration) + distributed tracing; p50/p95/p99 વાંચો. તેમની વચ્ચેનો *gap* વાર્તા કહે છે.
2. **Localize the stage** — દરેક step ને instrument કરો જેથી ધીમી requests ક્યાં સમય વિતાવે છે તે દેખાય; hunch પર optimize ન કરો.

```js
// p99 ક્યાં જમા થાય છે તે જોવા દરેક stage ને time કરો (guess ન કરો)
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'); // suspect
  res.json(courses);                         mark('total');
}
```

3. **Identify the tail suspect** — સામાન્ય રીતે *waiting*, computing નહીં: connection-pool exhaustion, N+1 queries, un-timed 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 માં collapse કરો -> tail ઘટે છે (હવે N sequential trips નહીં)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // one 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. **એક વસ્તુ fix કરો → p99 ફરી measure કરો → પુનરાવર્તન કરો.** એક સમયે એક variable, નહીંતર શું મદદ કરી તે તમને ખબર નહીં પડે.
5. **Lock it in** — એક **SLO** (દા.ત. p99 < 300ms) + alert સેટ કરો જેથી તે regress ન થાય.

## Interview lens
Interviewer એક *methodical* process ને probe કરે છે, નસીબદાર guess નહીં: શું તમે **tail ને mean થી** અલગ પાડો છો, બદલતા પહેલા measure કરો છો, અને **CPU પહેલા queues/locks (waiting)** ને જુઓ છો. નબળો જવાબ: "caching ઉમેરો / servers scale up કરો." મજબૂત જવાબ: measure → tracing થી localize → ચોક્કસ tail cause fix કરો → numbers થી verify કરો.

## Principle
**tail (p99) ને optimize કરો, average ને નહીં**. મોટાભાગનું "3s p99" *computing* કરતાં *waiting* (pool/queue/lock) માંથી આવે છે — તેથી CPU પહેલા queues જુઓ.

The process (from where to where)

Interview lens

Principle

સંબંધિત પ્રશ્નો