صفحة ويب أو واجهة برمجية بطيئة — كيف تجد السبب؟

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
```

انظر إلى **النسب المئوية وليس المتوسطات**: **p50** (المستخدم النموذجي) مقابل **p99** (أسوأ الحالات). يشير p50 سريع مع p99 بطيء إلى مشاكل عرضية — تنازع الأقفال أو ذاكرة التخزين المؤقت الباردة أو نسخة قاعدة بيانات بطيئة أو توقفات جمع القمامة — وليس مشكلة موحدة.

## تتبع النطاق البطيء

تُظهر أدوات APM (التتبع) بالضبط إلى أين يذهب الوقت داخل طلب:

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

يشير التتبع مباشرة إلى الاستدعاء المسيء. ثم تحقق من **التغييرات الأخيرة** — نشر أو فهرس مفقود أو نمو البيانات 10 أضعاف غالباً ما يفسر الانحدار المفاجئ.

## لماذا يهم

التخمين يضيع ساعات في تحسين الطبقة الخاطئة. القياس أولاً، تتبع النطاق البطيء، والنظر إلى **p50 مقابل p99** يحول "إنه بطيء" غامض إلى سبب محدد وقابل للإصلاح — وإعادة القياس تثبت أن الإصلاح نجح فعلاً.