ایک 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، ایک بغیر timeout کے external call)۔

**ذہنی ماڈل:** p99 *سب سے لمبی checkout line* ہے، اوسط انتظار نہیں — اوسط کو تیز کرنے سے اُس گاہک کو کوئی فائدہ نہیں جو پیچھے پھنسا ہوا ہے۔

## طریقہ کار (کہاں سے کہاں تک)
1. **ناپیں اور توڑیں** — RED metrics (Rate، Errors، Duration) + distributed tracing؛ p50/p95/p99 پڑھیں۔ اُن کے درمیان کا *فرق* کہانی بتاتا ہے۔
2. **stage کو localize کریں** — ہر step کو instrument کریں تاکہ دیکھ سکیں کہ سست requests وقت کہاں گزارتے ہیں؛ اندازے پر optimize نہ کریں۔

```js
// ہر stage کا وقت ناپیں تاکہ دیکھ سکیں 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 کے مشتبہ کی نشاندہی کریں** — عام طور پر *انتظار*، computing نہیں: connection-pool exhaustion، N+1 queries، بغیر timeout کے external calls، GC pauses، غائب 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)); // ایک 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 سبب کو ٹھیک کریں → اعداد سے تصدیق کریں۔

## اصول
**tail (p99) کو optimize کریں، اوسط کو نہیں**۔ زیادہ تر "3s p99" *انتظار* (pool/queue/lock) سے آتی ہے نہ کہ *computing* سے — لہٰذا CPU سے پہلے queues کو دیکھیں۔

طریقہ کار (کہاں سے کہاں تک)

انٹرویو کا زاویہ

اصول

متعلقہ سوالات