Tail Latency للمحترف: ليه P99 يكسر 5% من مستخدميك

القياس بأداة حقيقية

الأداة المعتمدة من LinkedIn و Grafana Labs لقياس percentiles بدقة تحت ضغط هي k6 أو wrk2. لازم تستخدم أداة بتعمل coordinated omission correction، عشان مفيش حاجة اسمها "متوسط الاستجابة" تحت الضغط من غير التصحيح ده (راجع كلام Gil Tene في Strange Loop 2015).

التشغيل: k6 run latency.js. الناتج بيرجّع P50 و P95 و P99 منفصلين. لو ولا threshold اتكسر، k6 بيرجع exit code != 0 — يعني تقدر تحطها في CI كـ gate قبل الـ deploy.

3 أسباب شائعة لارتفاع P99

1. Garbage Collection pauses: في الـ JVM وNode.js وGo، الـ GC بيوقف الـ thread لمدة 10-200ms. هتلاقي الـ P99 بيقفز بانتظام عند موعد الـ collection. الحل: monitoring لـ GC pause times، tuning للـ heap size، أو الانتقال لـ low-pause collector زي ZGC أو Shenandoah في الـ JVM.
2. Connection pool exhaustion: لو الـ pool عندك 50 اتصال DB وفيه 60 طلب متزامن، 10 طلبات بيستنوا في queue. الـ P50 ما يحسش، الـ P99 بيتضاعف لأن الطلبات اللي في الذيل هي اللي بتستنى الـ pool يفضى. الحل: قِس saturation للـ pool في Grafana، وارفع الحجم قبل ما يوصل 80%.
3. Cold cache بعد TTL expiration: أول طلب بعد انتهاء الـ TTL بياخد 800ms من الـ DB، باقي الطلبات في الـ TTL window بياخدوا 8ms من الكاش. ده بيظهر كـ spike دوري في الـ P99 كل فترة TTL. الحل: stale-while-revalidate أو background refresh قبل انتهاء الـ TTL.

الـ trade-offs لما تحاول تحسّن P99

تحسين الـ P99 له ثمن، ولازم يكون واضح قبل ما تبدأ.

بتكسب: تجربة أفضل لـ 1% من الطلبات. ده ممكن يكون 1% من المستخدمين الـ B2C (لو الطلبات موزعة بالتساوي)، أو شريحة كاملة من العملاء الـ B2B لو request واحد بيدخل في رحلة طويلة.

بتخسر: زيادة في استهلاك الذاكرة لو زوّدت connection pool أو heap. زيادة في تكلفة الـ infrastructure لو ضفت replicas. زيادة في complexity العملية لو طبّقت hedged requests (إرسال نفس الطلب لـ 2 servers والاكتفاء بالأسرع — التكلفة 2x للـ backend، والتوفير في latency حقيقي بس الفاتورة مضاعفة).

قاعدة عملية: لو شغلك B2C وفيه monetization مرتبط بكل طلب (بحث، شراء، مشاهدة)، تحسين P99 له ROI مباشر وقابل للقياس. لو شغلك internal tooling أو batch jobs، ركّز على throughput و P50 وسيب P99 لحالها.

متى لا تركّز على P99

• Batch processing: مفيش user جالس مستني. ركّز على throughput و time-to-completion للـ batch كاملاً.
• Async fire-and-forget endpoints: اللي بترجع 202 Accepted وبتشتغل في الخلفية. الـ P99 لـ accept response ميه يعني، الزمن الحقيقي في الـ worker.
• Endpoints بتاعت admin أو internal: أقل من 100 طلب/يوم، الـ percentiles مش statistically significant — أي طلب بطيء بيظهر كـ P99 خادع.
• Endpoints بترجع stream طويل: TTFB أهم من total duration، استخدم metric مختلف.

الخطوة التالية

افتح الـ Grafana بتاعك دلوقتي، وضيف panel جديد لكل critical endpoint بـ 4 خطوط: P50, P95, P99, P999. لو نسبة P99/P50 أكتر من 5x، عندك tail latency حقيقي. اكتب اسم الـ endpoint والنسبة الحالية والهدف اللي عايزه. وابدأ بالسبب رقم 2 من الجدول فوق (connection pool) — في 80% من الحالات هو الـ low-hanging fruit.

المصادر

• Dean, J. & Barroso, L. A. (2013). "The Tail at Scale". Communications of the ACM, 56(2), 74-80.
• Tene, G. (2015). "How NOT to Measure Latency". Strange Loop conference talk.
• k6 documentation, Thresholds reference: https://grafana.com/docs/k6/latest/using-k6/thresholds/
• Prometheus documentation, histogram_quantile() function reference.
• Brendan Gregg, "Systems Performance" (2nd ed., 2020), Chapter 2: Methodologies — discussion on percentiles vs averages.