تقنية

لماذا لا يعطي متوسط المئينات زمن الاستجابة الكلي؟

مئة مربع تمثل أزمنة طلبات مرتبة تصاعديًا، مع تحديد الرتبة الخامسة والتسعين ضمن مجموعة ثلاثمئة ملي ثانية
رسم أصلي لبيانات متخيلة: كل مربع طلب، ويجري العد من اليسار إلى اليمين سطرًا بعد سطر. الإطار الأسود يحدد الرتبة الخامسة والتسعين؛ الألوان تبين الزمن بالملي ثانية، وليس الخادم أو وقت الوصول.

لا ينتج المئين الكلي من متوسط مئينات الخوادم. [1] لنختبر ذلك بمئة طلب متخيل.

الخلاصة السريعة

اجمع معلومات التوزيع قبل حساب المئين؛ لا تجعل متوسط أرقام المئينات بديلًا عن مئين الطلبات كلها.

  • نستخدم طلبات ناجحة متميزة، في الفترة والوحدة وحدود القياس نفسها؛ لا نحول عدد الطلبات إلى عدد مستخدمين.
  • نختار قاعدة رتبة معلنة: نضرب العدد في خمسة وتسعين بالمئة، ثم نقرّب الموضع إلى العدد الصحيح الأعلى. [2]
  • في بياناتنا، خادم «أ» يعالج ثمانين طلبًا ومئينه مئة ملي ثانية، وخادم «ب» يعالج عشرين ومئينه ثلاثمئة.
  • متوسط المئينين مئتان، ومتوسطهما المرجح مئة وأربعون؛ كلاهما يختلف عن المئين المجمع في المثال.
  • بعد ترتيب الطلبات المئة، تقع الرتبة الخامسة والتسعون عند ثلاثمئة ملي ثانية، وتبقى خمسة طلبات أبطأ.
  • قد تتساوى أعداد الطلبات والمئينات المحلية في مجموعتين مختلفتين، بينما يختلف مئينهما المجمع؛ نعرض حالة تثبت ذلك.
  • المتوسط الحسابي الصحيح لبياناتنا مئة وثلاث وتسعون ملي ثانية؛ نحسبه من مجموع الأزمنة والعدد، وهو سؤال مختلف عن المئين.
  • احتفظ بتعريف القياس والفترة والطريقة ومصدر بيانات التوزيع، واكتب أن المئين غير قابل لإعادة الحساب إذا لم تحفظ إلا الملخصات المحلية.

ثبّت ما الذي يمثله كل طلب

يفرق دليل مراقبة الأنظمة في Google بين أزمنة الطلبات الناجحة والفاشلة، ويحذر من أن المتوسط قد يخفي طلبات بطيئة في طرف التوزيع. لذلك ينبغي أن نعرف الحالات التي نقيسها قبل تفسير رقم السرعة. [3]

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

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

اختر قاعدة حساب المئين قبل المقارنة

للمئينات طرائق حساب متعددة؛ يوضح توثيق NumPy اختلاف المقدرات، ومنها طريقة معكوس التوزيع التجريبي. في حسابنا سنرتب القيم ونأخذ الموضع الناتج من تقريب حاصل ضرب الكسر في العدد إلى الأعلى، دون استيفاء بين قيمتين. [2]

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

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

احسب مئين كل خادم من بياناته

نحدد بيانات الخادم «أ» كاملةً: ستة وسبعون طلبًا زمن كل منها مئة ملي ثانية، وأربعة طلبات زمن كل منها ألف ملي ثانية. المجموع ثمانون طلبًا. بعد الترتيب تشغل القيمة مئة المواضع من الأول إلى السادس والسبعين، ثم تأتي القيم الأربع الأكبر. موضع المئين المطلوب هو السادس والسبعون، ولذلك يكون مئين هذا الخادم مئة ملي ثانية وفق القاعدة التي اخترناها.

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

اكتب لكل خادم عمودًا للعدد وعمودًا للمئين، واحتفظ بجانب الورقة بقائمته الأصلية. ستكون الخلاصة المحلية: ثمانون ومئة للخادم الأول، وعشرون وثلاثمئة للثاني. لاحظ أننا اختصرنا عشرات القيم في رقمين لكل خادم. ستبدو الورقة المختصرة سهلة الجمع، لكن سهولة إجراء عملية على الأرقام لا تثبت أنها تجيب عن السؤال المطلوب. في الخطوة التالية سنجرب عمليتين ونقارن كلتيهما بالحساب المباشر.

اختبر المتوسط البسيط والترجيح

لا تصلح مئينات الملخصات المحسوبة مسبقًا للتجميع عبر المتوسط، وفق توثيق Prometheus. [1]

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

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

ادمج الطلبات ثم اقرأ الرتبة المطلوبة

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

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

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

لماذا لا تكفي المئينات والأعداد لاستعادة النتيجة؟

لننشئ حالة ثانية مستقلة، مع الحفاظ على عدد طلبات كل خادم ومئينه المحلي. نجعل طلبات «أ» الثمانين كلها عند مئة ملي ثانية. ونجعل لدى «ب» ثمانية عشر طلبًا عند مئة، وطلبًا عند ثلاثمئة، وطلبًا عند ألفين. هذه تعديلات صريحة على القوائم الأصلية، لا تصحيح لأرقامها. سيظل العددان ثمانين وعشرين، ويظل المئين المحلي مئة في الأول وثلاثمئة في الثاني.

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

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

افصل المئين عن المتوسط الحسابي للأزمنة

نعود إلى الحالة الأولى. مجموع أزمنة «أ» يساوي أحد عشر ألفًا وستمئة ملي ثانية: ستة وسبعون مضروبة في مئة، تضاف إليها أربعة مضروبة في ألف. بقسمة المجموع على ثمانين يكون المتوسط مئة وخمسًا وأربعين. مجموع أزمنة «ب» سبعة آلاف وسبعمئة، ومتوسطه ثلاثمئة وخمس وثمانون. هذه المرة حسبنا المتوسط من الأزمنة الأصلية، ولم نستخدم المئين المحلي بدلًا منها.

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

اكتب في التقرير رقمين منفصلين: المتوسط مئة وثلاث وتسعون، والمئين الخامس والتسعون ثلاثمئة. اختلافهما ليس تناقضًا، بل نتيجة لسؤالين مختلفين عن القائمة نفسها. وإذا استعملت عنوانًا عامًا مثل «سرعة الخدمة» فوق أحدهما، فقد يحسبه القارئ الآخر المقياس الثاني. سمِّ الإحصاء ووحدته ونافذته الزمنية بوضوح، واحتفظ بالحساب الذي أنتجه؛ فالتسمية جزء من قابلية مراجعة التقرير، وليست زينة بعد اكتمال الأرقام.

ما الذي تحفظه لتقرير يمكن إعادة حسابه؟

تحفظ المدرجات تمثيلًا للتوزيع قابلًا للتجميع، بخلاف المئينات المحلية؛ ويتطلب التجميع توافق التمثيل المستخدم. [1]

في تمريننا تكفي القائمتان الأصليتان مع اسم الخادم والعدد والوحدة والفترة وقاعدة الرتبة. أما إن وصلتك صورة للوحة فيها مئين كل خادم فقط، فدوّن أن الصورة لا تحتوي بيانات كافية لإنتاج المئين المجمع. لا تملأ الخانة الفارغة بمتوسط المئينات لكي يبدو التقرير كاملًا. ويمكن إرفاق القيم المحلية بوصفها محلية، مع طلب سجل مناسب أو نتيجة تجميع صحيحة من الجهة التي تدير القياس.

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

المصادر ومتابعة القراءة

  1. توثيق Prometheus: المدرجات والملخصات (يفتح في نافذة جديدة)prometheus.io
  2. توثيق NumPy: طرائق حساب الكميات (يفتح في نافذة جديدة)numpy.org
  3. دليل Google SRE: مراقبة الأنظمة الموزعة (يفتح في نافذة جديدة)sre.google

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.