کوئی ویب صفحہ یا API سست ہے — آپ وجہ کیسے تلاش کرتے ہیں؟

Question

Accepted Answer

**قیاس آرائی نہ کریں — پہلے پیمائش کریں۔** سستی کا سبب کلائنٹ، نیٹ ورک، سرور یا ڈیٹا بیس ہو سکتا ہے۔ ایک منطقی طریقہ یہ تلاش کرتا ہے کہ وقت *کہاں* جاتا ہے، اور پھر **سب سے بڑے حصے** کو بہتر بناتا ہے، بے ترتیب بہتری کی بجائے۔

## ایک منطقی ترتیب

```text
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
```

## پہلے پیمائش کریں: وقت کہاں ہے؟

براؤزر کے **Network/Performance** ٹیب اور سرور کی **timing** استعمال کریں تاکہ کل کو الگ کریں۔ ایک مفید تقسیم:

```text
Total 1200ms =
  DNS/connect      20ms
  server TTFB     900ms   ← the bottleneck is server-side
  download         80ms
  client render   200ms
```

**اوسط کی بجائے percentiles** دیکھیں: **p50** (عام صارف) بمقابلہ **p99** (بدترین صورت)۔ تیز p50 اور سست p99 بعض اوقات کے مسائل کی نشاندہی کرتا ہے — lock contention، سرد cache، سست DB replica، یا GC pauses — یہ یکساں مسئلہ نہیں ہے۔

## سست span کو ٹریس کریں

APM tools (traces) بالکل ظاہر کرتے ہیں کہ وقت کہاں جاتا ہے ایک درخواست میں:

```text
GET /orders                       950ms
  ├─ auth check                    10ms
  ├─ SELECT orders                 30ms
  └─ loop: SELECT user per order  900ms   ← N+1 query, the real cause
```

Trace براہ راست نقصان دہ کال کی طرف اشارہ کرتا ہے۔ پھر **حالیہ تبدیلیوں** کی جانچ کریں — ایک deploy، ایک غائب index، یا 10x ڈیٹا میں اضافہ اکثر اچانک regression کی وضاحت کرتا ہے۔

## یہ کیوں اہم ہے

قیاس آرائی غلط layer کو بہتر بنانے میں گھنٹے ضائع کرتی ہے۔ پہلے پیمائش کرنا، سست span کو ٹریس کرنا، اور **p50 بمقابلہ p99** دیکھنا ایک مبہم "یہ سست ہے" کو ایک مخصوص، قابل حل وجہ میں بدل دیتا ہے — اور دوبارہ پیمائش یہ ثابت کرتا ہے کہ حل واقعی کام کر گیا۔