زمن استجابة API: لماذا لا يكفي المتوسط؟ دليل قراءة P50 و P95 و P99 دون تضليل

لماذا يخدعك المتوسط؟

عندما تعلن لوحة المراقبة أن متوسط استجابة الخدمة 180 مللي ثانية، قد يتصور الفريق أن جميع المستخدمين يحصلون على تجربة سريعة. لكن ألف طلب سريع قد يخفي وراءه عشرات الطلبات التي استغرقت ثواني. المتوسط الحسابي يصف مجموع الأزمنة مقسومًا على عدد الطلبات، ولا يصف التوزيع ولا أسوأ تجربة. قبل أن تصدر حكمًا على الأداء، اذكر حجم العينة والفترة وطبيعة الطلبات، وهل احتُسبت الطلبات الفاشلة والملغاة. إن كان هدفك تقييم تجربة المستخدم فلا تختزلها في رقم واحد؛ اقرأ الوسيط والذيل ومعدل الأخطاء معًا، وراجع المسارات الحساسة تجاريًا بدل الاكتفاء بالمجموع العام.

حدد بداية الساعة ونهايتها

زمن معالجة الخادم ليس هو زمن انتظار المستخدم دائمًا. قد يبدأ القياس داخل تطبيق Node.js وينتهي عند إنشاء الاستجابة، بينما يواجه المتصفح أيضًا DNS و TLS وانتقال الحزم وانتظار الشبكة وعرض الصفحة. اكتب بوضوح هل تقيس مدة الخادم أم الرحلة الكاملة، وهل تشمل طوابير المعالجة وإعادة المحاولة. إذا كان الطلب يرسل مهمة خلفية ثم يعيد ردًا سريعًا، فقس زمن إنجاز المهمة مستقلًا؛ سرعة الرد الأول لا تثبت اكتمال العمل. تجنب المقارنة بين قياسات ذات حدود مختلفة، وأضف وحدة الزمن وآلية تسجيل الأحداث إلى تعريف كل مؤشر. أي تغيير في أداة الرصد قد يغير النتائج دون تغير الخدمة نفسها.

الوسيط P50 يصف الحالة المعتادة

رتب أزمنة الطلبات تصاعديًا ثم انظر إلى منتصف التوزيع. القيمة المحيطة بالمنتصف تسمى الوسيط أو P50، وتعني تقريبًا أن نصف القياسات يقع عندها أو دونها. افترض أزمنة 80 و 90 و 100 و 110 و 120 و 130 و 2200 مللي ثانية؛ الوسيط 110 بينما المتوسط أكبر بسبب القيمة الأخيرة. هذا مثال حسابي توضيحي وليس قياسًا لموقع بعينه. الوسيط مقاوم نسبيًا للقيم المتطرفة، لكنه قد يخفي مشاكل قليلة العدد وعالية الأثر. والأهم أن نصف الطلبات لا يساوي نصف المستخدمين: شخص واحد قد ينفذ مئات الطلبات، لذا احذر من تحويل المؤشر إلى ادعاء عن عدد الأشخاص.

كيف تقرأ P95 و P99؟

يشير P95 إلى حد تقع عنده أو دونه نحو 95% من قياسات الطلبات، بينما يعكس P99 شريحة أضيق وأبطأ. لا تساوِ P99 بأبطأ طلب على الإطلاق، ولا تتعامل مع قيمته بوصفها مستقرة في عينة من عشرين طلبًا. طرق الاستيفاء والحساب قد تختلف بين الأدوات، خاصة عند استخدام Histogram أو عينات جزئية. أرفق دائمًا عدد المشاهدات والفترة وتعريف النجاح وطريقة الحساب. إن كانت الزيارات قليلة، فقد يكون عرض القيم الخام أو نطاقات زمنية أو عدد الطلبات المتأخرة أكثر صدقًا من نسبة مئوية تبدو دقيقة. وعند مقارنة فترتين تأكد أن شروط القياس متطابقة.

مثال حسابي يكشف الذيل الطويل

تخيل 990 طلبًا استغرق كل منها 100 مللي ثانية، وعشرة طلبات استغرقت خمسة آلاف مللي ثانية. المتوسط يقارب 149 مللي ثانية فقط، مع أن عشرة طلبات انتظرت خمس ثوان. إذا كانت هذه الطلبات مرتبطة بالدفع أو حفظ النماذج، فقد يكون أثرها أكبر من عددها. المثال افتراضي ومقصود لتوضيح كيف يخفي المتوسط حالات نادرة. لا تتجاهل معدل المهلات أو نسبة الأخطاء؛ فإسقاط الطلبات البطيئة من البيانات عند تجاوز المهلة قد يجعل الرسم أجمل بينما تتدهور التجربة. قارن كذلك عدد الطلبات ومزيج العمليات قبل تفسير تغير المتوسط أو النسب المئوية.

قسّم المسارات قبل جمع الأرقام

خلط استجابة صورة صغيرة مع معالجة طلب دفع في توزيع واحد يجعل الرقم العام ضعيف الدلالة. قسم الطلبات بحسب الوظيفة: قراءة المحتوى، والبحث، والحفظ، والمعاملات، والعمليات الخلفية. لا تفرط في تقسيم البيانات إلى آلاف الوسوم الفريدة، لأن ذلك يرفع التكلفة ويقلل حجم كل عينة وقد يكشف معرّفات حساسة. عرّف لكل مجموعة ما تعنيه الاستجابة الناجحة والحد المقبول من منظور المستخدم. قد يتحسن P95 للبحث بينما يسوء P99 للدفع؛ كلاهما حقيقة تحتاج تفسيرًا مستقلًا. واعرض النسبة المئوية بجانب معدل الخطأ والتوافر وحجم المرور حتى لا يُفسر النجاح السريع الزائف كتحسن.

Histograms ليست سجلات خامًا

السجلات الخام تساعد في التحقيق في الطلبات الفردية لكنها قد تكون كبيرة ومكلفة أو خاضعة لأخذ عينات. Histogram يجمع أعداد القياسات ضمن حاويات زمنية محددة، فيسهل رسم التوزيع وتقدير النسب المئوية. يجب اختيار حدود الحاويات قرب عتبات الأداء المهمة؛ فالحاويات الواسعة تجعل تقدير P95 خشنًا. والأهم ألا تحسب P95 للخدمة بجمع متوسط P95 لخوادمها: النسب المئوية ليست أعدادًا خطية قابلة للتوسيط. اجمع الحاويات المتوافقة أو القياسات الخام أولًا ثم استخرج النسبة المطلوبة. دوّن نسخة الأداة وطريقة الحساب لأن اختلاف التنفيذ قد يفسر اختلافًا ظاهرًا بين لوحتين.

لا تجمع P95 بالمتوسط عبر الساعات

إذا كان P95 في ساعة هادئة 120 مللي ثانية وفي ساعة مزدحمة 900 مللي ثانية، فإن متوسط الرقمين لا يساوي بالضرورة P95 اليوم. قد تختلف أعداد الطلبات جذريًا، والنسبة المئوية لا تحافظ على معناها عند توسيط نتائج المجموعات. احسب المؤشر اليومي من توزيع كامل أو Histograms قابلة للتجميع، ثم احتفظ أيضًا بنافذة قصيرة من خمس أو عشر دقائق لكشف الذروات. قد تخفي نافذة يومية عطلًا استمر عشر دقائق. اعرض مؤشرات الذروة بجوار المتوسطات طويلة المدى، واحتفظ بخط زمني لأوقات النشر وتغير الحمل. لا تجعل تنعيم الرسم البياني يخفي مشكلة يراها المستخدم.

اختر المؤشر وفق سؤال القرار

استخدم P50 عندما تسأل عن الطلب المعتاد، و P95 عندما تريد فهم تجربة شريحة بطيئة ملحوظة، و P99 عندما تراقب ذيلًا نادرًا لكنه قد يؤثر في عمليات حساسة. المتوسط مفيد في بعض حسابات السعة والكلفة الإجمالية، لكنه لا يثبت أن التجربة جيدة. الحد الأقصى يصلح للتحقيق في حالة شاذة، لا لتقييم الاستقرار وحده. لا توجد قيمة سحرية مناسبة لكل المنتجات؛ استجابة محادثة فورية تختلف عن توليد تقرير طويل. اربط كل رقم بسؤال محدد، وحدد ما إذا كان القرار يتطلب تحسين زمن الواجهة أو قاعدة البيانات أو الاعتماديات الخارجية، ولا تحول كل ارتفاع في P99 إلى إنذار عاجل دون سياق.

ضع SLO قابلًا للاختبار

ابدأ برحلة محددة مثل حفظ مسودة أو إتمام دفع. عرّف ما يُعد نجاحًا، ومن أين يبدأ الوقت، وما المدة المقبولة للمستخدم، ثم اختر هدف خدمة SLO مع نافذة زمنية واضحة. يمكن افتراض هدف أن تنتهي 95% من عمليات الحفظ الناجحة خلال 800 مللي ثانية شهريًا، لكن الرقم مثال توضيحي وليس معيارًا عالميًا. أضف هدفًا مستقلًا للتوافر والأخطاء حتى لا تكافئ النظام على رفض الطلبات بسرعة. راجع الهدف مع فريق الدعم والمنتج وبيانات الاستخدام، ثم حدد ما سيحدث عند تجاوز ميزانية الخطأ. الهدف المفيد يوجّه القرار ولا يكتفي بتزيين لوحة التحكم.

افحص أسباب التحسن الظاهري

قبل إعلان تحسن بنسبة ثلاثين بالمئة، راجع عدد الطلبات وتوزيعها ونسبة التخزين المؤقت والأجهزة والبلدان ومعدل الأخطاء. قد ينخفض الزمن لأن الاستعلامات الصعبة أصبحت تفشل سريعًا، أو لأن المستخدمين غادروا، أو لأن جزءًا من الحركة لم يعد يُقاس. عند وجود إصدار جديد، قارن شرائح ثابتة قبل وبعد مع توثيق الفروق. لا تعتبر التزامن الزمني دليلًا على أن تغييرًا بعينه سبب التحسن؛ قد تكون هناك عوامل أخرى. استخدم سجلات التتبع للطلبات البطيئة بعد إخفاء البيانات الشخصية، وجرّب فرضية واحدة في كل مرة. إذا تحسن الذيل دون تغير الأخطاء والحمل تصبح النتيجة أقوى.

ابنِ لوحة قرار في ست خطوات

أولًا وثّق تعريف الطلب الناجح وبداية الساعة ونهايتها. ثانيًا اجمع عدد الطلبات ومعدل الأخطاء و Histogram للمدة. ثالثًا اعرض P50 و P95 و P99 بنوافذ قصيرة وطويلة. رابعًا قسم النتائج حسب نوع العملية مع حد معقول لعدد الوسوم. خامسًا ضع علامات على أوقات النشر والذروة والحوادث. سادسًا اختبر اللوحة بتأخير اصطناعي في بيئة اختبار، وتأكد أنها تكشف الذيل ولا تتجاهل الطلبات المنتهية بمهلة. اجعل لكل إنذار إجراءً تشغيليًا معروفًا: من يفحص؟ وأين يجد الدليل؟ ومتى يصعّد المشكلة؟ المؤشر الذي لا يغير قرارًا قد يحتاج إعادة تعريف.

أخطاء شائعة في تقارير الأداء

لا تستنتج أن واحدًا بالمئة من المستخدمين بطيئون لمجرد ارتفاع P99 للطلبات. لا تنس أن الطلبات المكررة بسبب retries قد تضخم العينة، وأن الساعة غير المتزامنة بين الخوادم قد تشوه قياس المدة. احذر من قياس زمن HTTP وحده عندما يستمر العمل الحقيقي في طابور. كذلك قد يرد التطبيق برمز 200 مع رسالة خطأ وظيفية. اكتب التحفظات بوضوح: حجم العينة، التغطية، حدود المراقبة، أثر التخزين المؤقت، والفرق بين الارتباط والسببية. هذا يمنع تحويل أرقام دقيقة ظاهريًا إلى قرارات مكلفة. ومن الأفضل عرض فترة ثقة أو نطاق عند صغر البيانات بدل عشرية زائفة.

مراجع وخلاصة قابلة للتطبيق

للمزيد راجع فصل المراقبة في كتاب Google SRE: https://sre.google/sre-book/monitoring-distributed-systems/ ، وتوثيق Prometheus لقياس Histograms و Summaries: https://prometheus.io/docs/practices/histograms/ ، ومرجع MDN Performance API: https://developer.mozilla.org/en-US/docs/Web/API/Performance_API . المصادر تشرح مبادئ عامة وقد تختلف تفاصيل التنفيذ بين الإصدارات. داخل إيجي تاج اقرأ دليل تشخيص نفاد ذاكرة Node.js على /ar/articles/nodejs-memory-leak-task-pressure-oom-killer-diagnosis . الخطوة العملية الآن هي اختيار مسار حساس واحد، وجمع توزيع الأزمنة والأخطاء لمدة أسبوع، ثم كتابة تقرير يفصل الوسيط عن الذيل ويذكر ما لم يُقَس.