تحميل اختبار مشروع على شبكة الإنترنت - لا النقدية

الأصدقاء ، مساء الخير!

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

لماذا تحميل اختبار مشروع الويب؟

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

• استعلامات MySQL (سنستخدم قاعدة البيانات الشائعة هذه كمثال) ، من خلال واجهة برمجة تطبيقات ملائمة إلى حد ما تستخدم الفهارس (على الرغم من أننا لا نرى كيف يتم استخدام الفهارس بدقة بواسطة المجدول ، ما هي أصلها)
• يتم تخزين نتائج تنفيذ استعلامات قاعدة البيانات وقطع كبيرة من التعليمات البرمجية
• قام المطور بفحص 3.14 مرة من بناء صفحة الويب في المتصفح وإذا لم تبطئ العين ، فكل شيء على ما يرام

غالبًا ما تعمل الاستدلال بشكل جيد ، ولكن كلما كان المشروع أكبر وأثقل ، قد يحدث خطأ ما مع احتمال متزايد بشكل كبير.

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

هذا هو السبب ، بالمناسبة ، لا يوصى باستخدام ذاكرة التخزين المؤقت لاستعلام MySQL المضمنة ، والتي تعاني من مشكلة مماثلة: إذا قمت بتغيير سجل جدول واحد على الأقل ، فسيتم إعادة تعيين ذاكرة التخزين المؤقت للجدول بالكامل (تخيل جدول يتكون من 100 ألف سطر وتصبح سخافة الموقف واضحة).

وضع مماثل مع استعلامات MySQL. إذا تم تنفيذ الاستعلامات بواسطة فهارس ، فسيتم بشكل عام تنفيذ الاستعلامات ... "بشكل أسرع". يمكنك تصديق أن وقت تنفيذ مثل هذه الاستعلامات يعتمد لوغاريتمياً على مقدار البيانات (O (log (n))). لكن من الناحية العملية ، غالبًا ما يتبين أن بعض الاستعلامات تؤثر على الآخرين ، باستخدام النظم الفرعية العامة لقاعدة البيانات في نفس الوقت (الفرز على قرص يبدأ في التباطؤ) ولا يمكنك التنبؤ بذلك على الفور.

أيضًا ، غالبًا أثناء التحميل ، يتم الكشف عن ميزات مثيرة للاهتمام في نظام التشغيل ، على وجه الخصوص ، تجاوز سعة منافذ عميل TCP / IP الصادرة أثناء العمل المكثف باستخدام memcached. أو انسداد اباتشي مع طلبات لمعالجة الصور ، ل أثناء التكوين ، نسوا تكوين معالجتهم بواسطة خادم وكيل التخزين المؤقت nginx.

في بعض الأحيان ينسون أن يثبتوا في MySQL مسار الجداول المؤقتة على القرص الذي يعين البيانات إلى ذاكرة الوصول العشوائي ("/ dev / shm") ، وبسبب ذلك ، عندما يزداد الحمل ، يخرج خادم قاعدة البيانات من عمليات فرز مكثفة.

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

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

كيفية تحديد أهداف اختبار الإجهاد؟

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

• صنع 1 مليون زيارة. متوسط ​​وقت بناء صفحة الويب = 1 ثانية. ماذا هذا العرض؟ أوه، لا شيء. ما المدة التي استغرقها اختبار الحمل؟ يمكن أن يكون وقت تنفيذ طلب واحد إما 1 مللي ثانية أو 600 ثانية ، ومن غير الواضح ما هي النسب الأكبر. وكم عدد الأخطاء التي حدثت (استجابة nginx بأسلوب "Error 50x") ليست واضحة أيضًا :-)
• صنع 1 مليون زيارة. متوسط ​​وقت إنشاء صفحة الويب = 1 ثانية ، وعدد أخطاء HTTP هو 0.5٪. ما الذي يظهره هذا؟ حتى الآن ، مفيد قليلا ، ولكن أفضل. حصة الأخطاء غير الكافية التي يمكن للعميل التقاطها ، نعلم بالفعل أنه أمر رائع ويمكنك البدء في التحضير والذهاب إلى الصيدلية. الوسيط متري أكثر مقاومة لـ "القيم المتطرفة" من المتوسط ​​(تقدير "أكثر قوة") ، وبالتالي ، فهو بلا شك أفضل من المتوسط ​​الحسابي. ولكن دعونا نجعل المقاييس أكثر فائدة.
• تم إجراء مليون زيارة يوميًا. تم إجراء 25 ٪ من الزيارات في أقل من 10 مللي ثانية ، وتم إجراء 50 ٪ من الزيارات في أقل من ثانية واحدة (وهذا هو المتوسط ​​أو 50 في المئة) ، وتم إجراء 75 ٪ من الزيارات في أقل من 1.5 ثانية ، وتم إجراء 95 ٪ من الزيارات في أقل من 5 ثوانٍ وعدد أخطاء HTTP هو 0.5٪ نرى نسبة الأخطاء غير الكافية التي يمكن للعميل التقاطها ، لكننا نرى أيضًا نسبة الطلبات التي يتم تنفيذها على عتبة معينة.

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

ليس هناك ما هو واضح: النسب المئوية ، المتوسطات ، الكميات ، المسودات ، التوزيع ...

كل شيء بسيط! الآن سوف أرسم وأعرض في بيئة جميلة لتحليل البيانات: Jupyter notebook / Python.

دعنا نقول أنه تم إجراء 10 مشاهدات على الموقع مع مرور الوقت بالميلي ثانية:



الآن فرز الوقت الذي يستغرقه لإكمال الزيارات في ترتيب تصاعدي:



نحن على بعد خطوة واحدة من فهم المتوسطات ، 25 و 75. كل شيء بسيط - نقسم المخطط إلى نصفين وفي الوسط سيكون هناك "وسيط" (الرقم 1 على الرسم البياني). سيتوافق الربع الأول من الرسم البياني مع النسبة المئوية 25 (الرقم 2 على الرسم البياني) والربع الثالث يتوافق مع النسبة المئوية 75 (الرقم 3 على الرسم البياني). وفقًا لذلك ، يتم الحصول على النسب المئوية الأخرى (أو ، كما يطلق عليها أيضًا ، الكميات) - 90 ، 95 ، 99 ، إلخ:



وسوف يبدو وكأنه التوزيع (الرسم البياني) على مدى وقت تنفيذ الزيارات المذكورة أعلاه. كما ترون ، كل شيء واضح وبسيط للغاية:



وهذه هي الطريقة التي يمكنك بها بناء توزيع (المدرج التكراري) بسرعة بناءً على سجل طلب اختبار التحميل. تعديل إلى تنسيق السجل الخاص بك:

#!/bin/bash TOTAL=`cat /var/log/nginx.access.log | wc -l` echo "Total:" $TOTAL cat /var/log/nginx.access.log | awk -F'->' '{ $2=$2*1000; zone = int($2/100)*100; hits[zone]++; } \ END {for (z in hits) {printf("%8s ms: %8s,%6.2f% ",z,hits[z],hits[z]/total*100);{s="";a=0;while(a++<int(hits[z]/total*100)) s=s"*";print s} } }' \ total="$TOTAL" - | sort -n 

وتحصل على شيء مثل هذا:



آمل الآن أن أصبح كل شيء واضحًا وفي مكانه. إذا لم يكن كذلك ، اسأل في التعليقات.

اختبار الإجهاد الوقت

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

تحميل موازنة

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

• الصفحة الرئيسية - الأخبار - أخبار مفصلة = 50 ٪
• الصفحة الرئيسية - نظرة عامة على الكتالوج - الكتالوج المفصل = 30٪
• كتالوج مفصل - نظرة عامة على الكتالوج - كتالوج مفصل = 15 ٪
• نتائج البحث - فهرس مفصل = 5 ٪

في البرنامج لإنشاء تحميل (نستخدم غالبًا في كثير من الأحيان) ، يتم إنشاء العديد من تدفقات التحميل لكل سلسلة بحيث ، مع مراعاة الفاصل الزمني بين مرات الدخول في السلسلة ، يرتبط إجمالي عدد مرات الدخول لكل سلسلة لكل وحدة زمنية على النحو التالي: 50٪ ، 30٪ ، 15٪ ، 5٪ .

من السهل القيام بحساب الفواصل الزمنية وتدفقات الحمل في Excel أو على ورقة بقلم رصاص.

هيكل سلسلة الحمل

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



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



بين الزيارات ، بالطبع ، تحتاج إلى إيقاف مؤقت - حتى نقترب من الحمل الناتج عن المستخدمين الحقيقيين. لا تنس حفظ وإرجاع قيم ملفات تعريف الارتباط إلى الخادم:



من السهل تكوين المتغيرات العامة لسلاسل التحميل ، بما في ذلك عدد سلاسل العمليات الخاصة بها. يمكن بعد ذلك استخدام بعض المتغيرات العامة في أماكن مختلفة في سلاسل التحميل:

كيفية جعل اختبار الإجهاد ينتهي بأمان؟

في الممارسة العملية ، في الغالب ، تعطل اختبار الحمل في الدقائق أو الساعات الأولى نظام الويب ، ويبدأ كل شيء بالتدخين ، ثم يحترق ، ولا يفتح الموقع ، ويقع MySQL في مقايضة ولا يسمح لنفسه بالاتصال ، وتقارب LA على الخوادم 100 ، ويبدأ المطورون التشغيل بعبارة "هذا لا يجب أن يحدث" ، وعادة ما يجيب مسؤولو النظام بابتسامة "هناك عدالة في الحياة!" وابدأ في شرب البيرة في غرفة الخادم.

ولكن من أجل فهم سبب سقوط كل شيء وما الذي يجب إصلاحه ، من أجل إظهار نتائج اختبار الحمل "الناجح" للعميل في يوم واحد ، يجب أولاً تمكين تسجيل المقاييس الرئيسية لحياة نظام التشغيل - من السهل القيام بذلك في منتجات munun / cacti المجانية.

سأذكر ما يحدث أثناء انهيار نظام الويب في أغلب الأحيان وكيف يمكن إصلاح ذلك.

أولاً وقبل كل شيء ، يتم "انسداد" خادم الويب apache أو php-fpm مع الطلبات:



يحدث هذا غالبًا بسبب انهيار MySQL - يتزايد عدد تدفقات الاستعلام المعلقة:



ما هو السبب في ذلك؟ غالبًا ما ينسون من الأعلى تقييد عدد تدفقات apache أو استعلام الاستعلام على MySQL ، مما يؤدي إلى تسرب التطبيقات من ذاكرة الوصول العشوائي إلى مقايضة بطيئة بالتشنجات:



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



ومع ذلك ، في بعض الأحيان تكون المشكلة على جانب النظام الفرعي للقرص البطيء. في هذه الحالة ، ترتفع LA بشكل حاد وتقترب النسبة المئوية لاستخدام القرص من 100 (الرسم البياني الأيمن السفلي):





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

تفسير نتائج اختبار الإجهاد

عادة ، بعد إعادة التشغيل والتعديلات من 5 إلى 10 ، يبدأ اختبار الحمل رحلته ويكتمل بنجاح. نتيجةً لذلك ، يجب أن يكون لديك مجموعة من هذه السجلات تقريبًا لمزيد من التحليل:

• سجل الطلبات إلى nginx مع وقت طلب العميل (في هذه الحالة سيتم تحميل البرنامج) ، وقت الوكيل من nginx إلى apache / php-fpm
• سجل أخطاء nginx
• سجل طلب apache / php-fpm مع وقت معالجة الطلب وحالة استجابة HTTP
• سجل خطأ apache / php-fpm
• الخلية البطيئة سجل
• سجل خطأ الخلية

بالإضافة إلى ذلك ، يجب أن يكون هناك رسوم بيانية تحليلية على مدار اليوم الماضي حول استخدام وحدة المعالجة المركزية ، والأقراص ، و MySQL ، و RAM ، وعمال apache ، إلخ. (انظر أعلاه أمثلة من الرسوم البيانية مونين).

باستخدام هذه الأعمال الفنية ، يمكنك ، باستخدام برنامج نصي awk بسيط في بداية المنشور ، إنشاء توزيعات (رسوم بيانية) على هذه السجلات وحساب عدد وأنواع أخطاء HTTP. في الواقع ، يمكنك إنشاء تقرير عن نجاح اختبار الإجهاد حول هذا المحتوى الذي هو رحيب ومفيد للغاية للأعمال التجارية وصنع القرار:

خلال اليوم قدمت 1 مليون زيارة. تم إجراء 25٪ من الزيارات في أقل من 50 مللي ثانية ، وتم إجراء 50٪ من الزيارات في أقل من 0.5 ثانية (متوسط) ، وتم إجراء 75٪ من الزيارات في أقل من ثانية واحدة ، وتم إجراء 95٪ من الزيارات في أقل من 5 ثوانٍ ، وعدد أخطاء HTTP - 0.01 ٪. بيانات الاختبار: تم إغراق الكتالوج والمستخدمين والأخبار والمقالات في مجلد قريب من المتوقع. مطور واحد أطلق النار على نفسه.

سلاسل التحميل:

الصفحة الرئيسية - الأخبار - أخبار مفصلة = 50 ٪
الصفحة الرئيسية - نظرة عامة على الكتالوج - الكتالوج المفصل = 30٪
كتالوج مفصل - نظرة عامة على الكتالوج - كتالوج مفصل = 15 ٪
نتائج البحث - فهرس مفصل = 5 ٪

رسوم استخدام موارد الخادم:
...

هذا تقرير جيد ومفهوم عن اختبار تحميل نظام الويب. لمحبي الألم الحاد ، لا يزال بإمكانك التوصية أثناء اختبار التحميل بتضمين كل دقيقة استيراد / تصدير البيانات إلى موقع ويب من أنظمة فئة SAP ، 1C ، إلخ. والاتصالات المتزامنة عبر مآخذ TCP / IP مع خدمات التبادل الخارجي ، على سبيل المثال ، cryptocurrency :-)

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

من أين يأتي اختبار الإجهاد؟

بالمناسبة ، نعم ، لم نبرز هذه اللحظة. لأسباب تافهة ، فإن عدم وجود توازن بين عمال nginx - apache - mysql عادة ما ينبثق. أي لا يقتصر العمال على ما سبق ، ونتيجة لذلك ، يمكن أن يصل 500 عامل (كل منهم في بعض الأحيان 100 ميجابايت) على الفور في أباتشي وسيأتي 500 موضوع مع طلبات إلى MySQL على الفور - مما سيؤدي إلى زيادة في أخطاء HTTP 50x والانهيار المحتمل.

هنا يوصى بتحديد عدد عمال apache / php-fpm على العدد الذي يناسب ذاكرة الوصول العشوائي ، وبالمثل ، الحد من عدد مؤشرات الترابط في MySQL للحماية من تجاوز ذاكرة الوصول العشوائي المتاحة. الفكرة بسيطة - دع العملاء ينتظرون أمام nginx ، ويمكن أن يبطئوا قليلاً من مآخذ TCP / IP غير المتزامنة وغير المحظورة ، والتي "تنكسر" فورًا في apache / MySQL.

من أكثر الأسباب المزعجة ، قد يكون هناك PHP segfault. في هذه الحالة ، تحتاج إلى تمكين جمع coredump واستخدام gdb لمعرفة سبب حدوث ذلك. في معظم الحالات ، يمكن التغلب على المشكلة من خلال تحديث / تكوين PHP.

ما تبقى وراء الكواليس

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

على أي حال ، إذا أظهرت نتائج اختبار الإجهاد في الخلفية الخلفية أعدادًا جيدة ، واستمر الموقع في التباطؤ في المتصفح ، فمن الواضح بالفعل من "يضرب الوجه الأحمر الوقح" :-)

على محمل الجد ، في المشاركات القادمة نأمل أن نغطي هذا الموضوع المهم.

الملخص والاستنتاجات

المجموع - لا يوجد شيء معقد في تنظيم وإجراء اختبار الحمل لنظام الويب مفيد للتطوير والأعمال.

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

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

حظا سعيدا أيها الأصدقاء وطرح الأسئلة في التعليقات!