متى تتجنب استخدام الـ Average لقياس أداء الانظمة

كثيرا ما يُستخدم المتوسط الحسابي (Average/Mean) عند مراقبة الأنظمة لتجميع القيّم وأخذ فكرة عامة عنها لكنه ليس أنسب عملية لتجميع البيانات دائما فهو لا يعطي صورة دقيقة عن الأداء.

مثال على قياس API Latency

لإعطاء مثال على ذلك، سنفترض أننا نقيس API Latency لأحد الأنظمة، الشكل الآتي يوضح الـ Latency لكل request (بدون أي حسابات إضافية، اعتبر ان كل نقطة على محور x هي request مختلفة):

نلاحظ من الرسم البياني أن الـ Requests متباينة في السرعة، فبعضها سريع جدا والآخر بطيء جدا، وبينهما تقع كثير من البيانات.

لو حسبنا المتوسط بجمع القيم وقسمتها على عددها سنحصل على 696.04ms، الرقم لا يعبر عن مدى بطئ وسرعة الـ API، أعلى قيمة ضمن البيانات السابقة 5231ms تؤثر بشكل كبير على المتوسط وترفعه (فالمتوسط بدونها يصبح 507.08ms)

المتوسط يوضح مركز ثقل البيانات، والـ Percentile أداة أكثر دقة

المتوسط في هذه الحالة يشرح أين “مركز ثقل” الأرقام.. فكلما زاد عدد الـ requests البطيئة سيرتفع الرقم، وكلما قلت سينخفض، عدد قليل من القيم المتطرفة قد يرفع الـ Average بشكل كبير.

الأداة الأنسب لفهم البيانات في مثل هذه الحالة هي الـ Percentile وهي مجموعة من القيم تقع تحتها نسب مئوية معينة من البيانات المرتبة، تتم الاشارة إليها عادة بحرف P متبوعا برقم النسبة المئوية المطلوب، الجدول الآتي يوضح الفكرة:

الـ Percentile تعطيك فكرة أكثر دقة عن البيانات، فقيمة P50 تعطي فكرة عن التجربة الطبيعية للمستخدم، بينما P95 تعطي فكرة عن تجربة معظم المستخدمين، و P99 تعطي فكرة عن الحالات المتطرفة.

فلو أردنا إضافة تنبيه (Alert) عند زيادة الـ Latency، وليكن الحد الفاصل هو 700ms، استخدام الـ Average لن يكون دقيقا أبدا، ففي المثال السابق، الـ Average كان أقل من 700ms مع وجود قيم بطيئة جدا تصل إلى عدة ثوانٍ، بينما استخدام P99 يعني أن التنبيه سيعمل إذا تجاوز 1% من البيانات هذا الرقم، و P95 يتحقق من 5% من الأرقام، مما يعطيك تحكما أكبر وإمكانية لاستثناء القيم المتطرفة التي يصعب التعامل معها بشكل سريع.