ஒரு API-இன் p99 latency 3s — அதை எப்படி debug செய்து optimize செய்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: மெதுவான 1% requests 3s எடுக்கின்றன. முதல் நகர்வு **அளந்து, பிரித்துப் பார்ப்பது, யூகிப்பது அல்ல**. p50 vs p99-ஐ ஒப்பிடுங்கள் — p50 வேகமாக இருந்தும் p99 3s ஆக இருந்தால், path சீராக மெதுவாக இல்லை; ஏதோ ஒன்று *load-இன் கீழ் அல்லது edge cases-இல் மட்டுமே* கடிக்கிறது (pool saturation, GC pauses, N+1, cold cache, timing இல்லாத ஒரு external call).

**சிந்தனை மாதிரி:** p99 என்பது சராசரி காத்திருப்பு அல்ல, *மிக நீளமான checkout வரிசை* — சராசரியை வேகப்படுத்துவது பின்னால் மாட்டிக்கொண்ட வாடிக்கையாளருக்கு எதுவும் செய்யாது.

## செயல்முறை (எங்கிருந்து எங்கே)
1. **அளந்து பிரிக்கவும்** — RED metrics (Rate, Errors, Duration) + distributed tracing; p50/p95/p99-ஐப் படியுங்கள். அவற்றுக்கு இடையேயான *இடைவெளி* கதையைச் சொல்கிறது.
2. **stage-ஐ localize செய்யவும்** — மெதுவான requests எங்கே நேரம் செலவிடுகின்றன என்பதைப் பார்க்க ஒவ்வொரு step-ஐயும் instrument செய்யுங்கள்; ஒரு யூகத்தின் மேல் optimize செய்யாதீர்கள்.

```js
// p99 எங்கே குவிகிறது என்பதைப் பார்க்க ஒவ்வொரு stage-ஐயும் time செய் (யூகிக்காதே)
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. **tail-இன் சந்தேகத்திற்குரியதை அடையாளம் காணவும்** — பொதுவாக computing அல்ல, *காத்திருப்பு*: connection-pool exhaustion, N+1 queries, timing இல்லாத external calls, GC pauses, missing index, cold cache.

```js
// முன்: N+1 — N தொடர்ச்சியான round-trips, N வளர வளர p99 வெடிக்கிறது
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// பின்: 1 query-ஆகச் சுருக்கு -> tail குறைகிறது (இனி N தொடர்ச்சியான 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-ஐ மீண்டும் அளந்து → மீண்டும் செய்.** ஒரு நேரத்தில் ஒரு variable, இல்லையெனில் எது உதவியது என்று உங்களுக்குத் தெரியாது.
5. **அதை நிலைநிறுத்து** — ஒரு **SLO** (எ.கா. p99 < 300ms) + alert அமைக்கவும், இதனால் அது regress ஆகாது.

## நேர்காணல் பார்வை
ஒரு அதிர்ஷ்ட யூகம் அல்ல, ஒரு *methodical* செயல்முறையை நேர்காணல் செய்பவர் ஆராய்கிறார்: **tail-ஐ mean-இலிருந்து** வேறுபடுத்துகிறீர்களா, மாற்றுவதற்கு முன் அளக்கிறீர்களா, மேலும் CPU-க்கு முன் **queues/locks (காத்திருப்பு)**-ஐப் பார்க்கிறீர்களா. பலவீனமான பதில்: "caching சேர் / servers-ஐ scale up செய்." வலுவான பதில்: அளந்து → tracing மூலம் localize → குறிப்பிட்ட tail காரணத்தை fix → எண்களுடன் சரிபார்.

## கொள்கை
**Tail (p99)-ஐ optimize செய், சராசரியை அல்ல.** பெரும்பாலான "3s p99" *computing*-ஐ விட *காத்திருப்பிலிருந்து* (pool/queue/lock) வருகிறது — எனவே CPU-க்கு முன் queues-ஐப் பாருங்கள்.

செயல்முறை (எங்கிருந்து எங்கே)

நேர்காணல் பார்வை

கொள்கை

தொடர்புடைய கேள்விகள்