تحليل التوزيع غير الدقيق لـ Wrk Latency

wrk هو أداة رائعة لاختبار الضغط على HTTP تم بناؤها على أساس المشاريع مفتوحة المصدر مثل Redis وNGINX وNode.js وLuaJIT، مستفيدة من نقاط قوتها في التعامل مع الأحداث، وتحليل HTTP، والأداء العالي، والمرونة، بالإضافة إلى القدرة على كتابة نصوص Lua الخاصة بك لإنشاء طلبات الاختبار.

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

فيما يلي الجزء الإحصائي لتوزيع التأخير من نتائج wrk.

    Latency Distribution
     50%    1.20ms
     75%  595.78ms
     90%  899.11ms
     99%    1.00s

هذا المثال يعني أن 50% من الطلبات تم إكمالها في 1.2 مللي ثانية، و90% من الطلبات تم إكمالها في 899 مللي ثانية، و99% من الطلبات تم إكمالها في ثانية واحدة.

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

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

عندما نواجه مشاكل في التأخير، فإن رد فعلنا الأول هو أن هناك انسدادًا في مكان ما في الكود أو النظام. نظرًا لأن النظام معقد، فإننا نقدم مخططات اللهب.

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

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

الآن الهدف واضح، وهو فقط تنعيم الكود الخاص بـ wrk حول إحصائيات التأخير. أكبر قلق هو أن هناك خطأ في الإحصائيات الداخلية لـ wrk، وهو ليس سهل الإصلاح، خاصة أنه مشروع بدون أي حالات اختبار.

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

    if (complete / cfg.connections > 0) {
        int64_t interval = runtime_us / (complete / cfg.connections);
        stats_correct(statistics.latency, interval);
    }

وفقًا لهذا الشرط، سيتم تصحيح البيانات كلما تم إنشاء بيانات قياسية. إذا كنت مهتمًا، يمكنك الاطلاع على كود دالة stats_correct، فهو يتكون من 10 أسطر فقط، ولم أفهمه حتى بعد قراءته عدة مرات.

تحقق من سجل الالتزامات مرة أخرى، قد يكون هناك شيء ما، ولكن فقط السطر التالي، ولم أفهمه:

remove calibration & improve CO correction

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

تم التحقق من المشكلة هنا، ويمكن تأكيد أنها ليست مشكلة في المنتج، والحل موجود بالفعل، وهو تعليق الكود المصحح أعلاه. ولكن يجب أن يكون هناك سبب لقيام مؤلف wrk بإضافته عمدًا، وعدم فهم السبب يظل مشكلة خفية. بطبيعة الحال، اضطررت إلى فتح issue لسؤال المؤلف، وwg، الذي يظهر مرة واحدة في السنة، رد بعد 15 يومًا، واتضح أن الاختصار CO في معلومات الالتزام أعلاه يشير إلى Coordinated Omission، وأعطى مقالة مخصصة لهذه المشكلة، يمكن للطلاب المهتمين البحث باستخدام هذا الكلمة المفتاحية.

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

Gil Tene، الذي اقترح مشكلة CO، قام أيضًا بإجراء تعديل على wrk لمعالجة مشكلة CO بشكل خاص: https://github.com/giltene/wrk2، وفي ملف README لهذا المشروع هناك بعض الشروحات حول هذا الموضوع، يمكنك قراءتها إذا كنت مهتمًا، لذلك لن أذكرها هنا.

بالنسبة لمنتجنا الخاص، بالتأكيد لا يوجد انسداد في الكود، وعند إجراء اختبارات الضغط، يتم تشغيل وحدة المعالجة المركزية بالكامل. حتى إذا كان هناك انسداد، هناك مخطط لهب لأخذ العينات وتحليلها. لذلك فإن التصحيح البسيط والقاسي الذي يقوم به wrk هنا لـ Coordinated Omission مضلل إلى حد ما.