تحليل نتائج اختبار التحمل

كل يوم في العالم هناك المزيد والمزيد من الأدوات لإجراء اختبار الإجهاد. في الواقع ، بدأ الاهتمام بهذا الموضوع في النمو.

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



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







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



نحن في Tinkoff نستخدم أداة Gatling بنشاط ، لذلك ، باستخدامها كمثال ، سنخبرك بكيفية إنشاء تقرير عن أحلامك وأين تبحث عنه عند تحليله. أريد أيضًا أن أشير على الفور إلى أنه يمكن الحصول على جميع المخططات الموضحة في المقالة تقريبًا عبر الإنترنت باستخدام حزمة من أداتك مع Grafana. إنها الأداة الأكثر ملاءمة لإنشاء التقارير على الفور باستخدام لوحة معلومات معدة مسبقًا. علاوة على ذلك ، يتيح لك إنشاء أي رسم بياني تقريبًا بسرعة أكبر بناءً على البيانات التي ترسلها. توجد بالفعل لوحات معلومات جاهزة لجميع أدوات اختبار الحمل تقريبًا. سيتم أيضًا تقديم الرسوم البيانية للأدوات الأخرى - MF LoadRunner و Apache JMeter - ، وتحليلها مبني على القياس مع Gatling.

المقاييس الأساسية

المؤشرات

يُظهر التوزيع الكمي والنسبة المئوية لوقت استجابة الطلب حسب المجموعة. تعد المخططات من هذا النوع ملائمة للاستخدام لإعطاء تقييم أولي سريع لنتائج الاختبار دون تحليل أعمق للمخططات الأخرى.



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

• ممتاز - وقت الاستجابة أقل من 50 ثانية ؛
• متوسط ​​- أكثر من 50 ، ولكن أقل من 100 ثانية ؛
• رهيب - أكثر من 100 ثانية.

في Gatling ، يمكنك بنفسك تكوين العتبات للانتقال من مجموعة إلى أخرى ورقمها في ملف gatling.conf. من الأفضل بناء مخططات من هذا النوع بناءً على المنهجية. APDEX (مؤشر أداء التطبيق)

يمكنك أيضًا إضافة مؤشر بعدد / نسبة الطلبات الفاشلة.







تتيح لك طريقة APDEX استخدام المؤشرات في اختبار الانحدار لمقارنة الإصدارات: وبهذه الطريقة يمكنك على الفور معرفة مدى سوء أو تحسن الإصدار بشكل عام. لسوء الحظ ، هذا الرسم البياني ليس خارج الصندوق في MF LoadRunner و Apache JMeter ، ولكن من السهل إنشاؤه باستخدام لوحة معلومات Grafana.

جدول وقت الاستجابة

بشكل افتراضي ، ينشئ Gatling جدولًا بناءً على النسب المئوية ومتوسط ​​وأقصى أوقات الاستجابة والأخطاء. يتتبع تجاوز SLA (زيادة المتطلبات غير الوظيفية). بشكل نموذجي ، تشير اتفاقيات مستوى الخدمة إلى النسب المئوية 95 و 99 والنسبة المئوية للأخطاء. وبالتالي ، يسمح لك الجدول بتقييم نتائج الاختبار بسرعة.



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

مخطط المستخدمين الظاهري

يُقاس عادةً بالقطع ويظهر كيف يدخل المستخدمون إلى التطبيق ، وبالتالي يوضح ملف تعريف الحمل الحقيقي. وتجدر الإشارة على الفور إلى أن هذه الرسوم البيانية في MF LoadRunner و Gatling تعرض عدد المستخدمين الظاهريين ، وبالنسبة لـ Apache JMeter - عدد الخيوط.



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

ينقسم هذا الرسم البياني إلى نوعين:

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

يعتمد نوع الرسم البياني أيضًا على نموذج التحميل:

• النموذج المغلق - يجب على المستخدمين تسجيل الدخول إلى النظام وفقًا لملف تعريف الحمل المخطط له. إذا أظهر الرسم البياني انخفاضات أو قمم ، فهذا يشير إلى أن الحمل لم يذهب وفقًا للسيناريو المحسوب أو المخطط ، ويتطلب مزيدًا من الدراسة.
• — , . , . , , / . , — .

Response Time

غالبًا ما يتم قياسه بالمللي ثانية - يُظهر وقت الاستجابة للطلبات المرسلة إلى التطبيق. يجب ألا يتجاوز وقت الاستجابة SLA. هذا الرسم البياني هو الأداة الرئيسية لإيجاد نقاط التدهور أثناء اختبار الحمل.



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



بالإضافة إلى الرسم البياني لوقت الاستجابة لكل طلب ، من الملائم أيضًا إظهار سطر مع وقت الاستجابة الإجمالي (إجمالي وقت الاستجابة). من خلال تراكب مخطط الحمل المطبق (VU / RPS) ، يمكنك تتبع الارتباط مع زيادة وقت الاستجابة من زيادة الحمل المطبق (VU / RPS). يسمي Apache JMeter هذا الرسم البياني Response Times vs Thread.



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

اختلافات الرسم البياني

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



في اختبار الأداء ، غالبًا ما يتم استخدام النسب المئوية 95 و 99 من أجل الوضوح. ومع ذلك ، إذا نظرت إلى متوسط ​​وقت الاستجابة ، يجب أن تأخذ في الاعتبار الانحراف المعياري (جذر متوسط ​​التربيع).

توزيع وقت الاستجابة

هناك أيضًا رسوم بيانية ممتازة توضح اعتماد توزيع الوقت على عدد الطلبات.



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

Latency

من هذا المقياس ، يمكن أيضًا تمييز زمن انتقال معلمة إضافية (مللي ثانية) - وقت الاستجابة (غالبًا ما يُفهم هذا على أنه زمن انتقال الشبكة). تُظهر هذه المعلمة الوقت بين نهاية إرسال الطلب حتى استلام حزمة الاستجابة الأولى من النظام.

باستخدام هذه المعلمة ، يمكنك أيضًا قياس زمن الانتقال على مستوى الشبكة في حالة نمو المعلمة. من المستحسن أن تميل إلى الصفر. يتم استخدام هذا النوع والنوع التالي من الرسوم البيانية بشكل أساسي للتحليل العميق وإيجاد مشاكل الأداء. هذا الرسم البياني ليس خارج الصندوق في جاتلينج. في MF LoadRunner ، يُسمى هذا الرسم البياني متوسط ​​زمن الانتقال في كتلة Network Virtualization Graphs إذا كنت قد قمت بتثبيت وكلاء المراقبة.

عرض النطاق

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



من خلال تغيير هذه المعلمة في أداة التحميل ، يمكنك محاكاة مصادر مختلفة للاتصالات بالتطبيق: شبكة 4G المتنقلة أو شبكة سلكية. لا يحتوي الإصدار المجاني من Gatling على هذا الرسم البياني ، فهو متاح فقط في النسخة المدفوعة من Gatling FrontLine. هذا الرسم البياني خارج الصندوق فقط في MF LoadRunner ، وهو موجود في نفس الكتلة مثل Latency ، ويسمى متوسط ​​الرسم البياني لاستخدام عرض النطاق الترددي.

طلب الرسم البياني في الثانية

مُقاس بالقطع في الثانية - يُظهر عدد الطلبات التي تدخل النظام في ثانية واحدة.



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

1. VU, RPS/TPS , .
2. Response Time, , .

TPS

يتم قياسه بالقطع في الثانية ويظهر عدد المعاملات (يمكن أن يكون هناك العديد من الطلبات داخل المعاملة) في ثانية واحدة.



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

مخطط الأخطاء

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



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



لا يحتوي جاتلينج افتراضيًا على رسم بياني منفصل يعرض الأخطاء فقط. في Gatling ، يتم دمجه مع الرسم البياني VU ويظهر على الفور كيف تؤثر الزيادة في الحمل على زيادة عدد الأخطاء ، ويساعد على اكتشاف العتبة التي يتم من خلالها تجاوز SLA أو ظهور الأخطاء على الإطلاق. لا يحتوي Apache JMeter أيضًا على جدول منفصل ، حيث يتم دمجه مع الرسوم البيانية لعدد المعاملات.

حالة استجابات HTTP

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



على سبيل المثال ، إذا حصلت على 100٪ في الرسم البياني السابق ، فستبدأ في تحليل أخطاء 50x التي ترجع إلى عدم استجابة الخادم ، أو أخطاء 403 بسبب التجمع الخطأ ولا يمكن للمستخدمين تسجيل الدخول ، على سبيل المثال ، أنت تستخدم بروتوكول HTTP.

في البداية ، لا يحتوي الإصدار المجاني من Gatling على هذا المخطط ، فهو متاح فقط في النسخة المدفوعة من Gatling FrontLine. لكي يظهر الرسم البياني في الإصدار المجاني ، تحتاج إلى إعادة تكوين logback.xml بحيث يتم جمع السجلات في Graylog ، وداخلها بالفعل لإنشاء الرسم البياني المطلوب.

رسم بياني للإنتاجية

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

يتم استخدامه عادة للتحليل العميق لمشكلة التطبيق. يحتوي Gatling على هذا الرسم البياني فقط في FrontLine ، وهو ليس في الإصدار المجاني.

التعديلات الممكنة

1. Response Time, , (Throughput). Response Time, Throughput , : - .
2. Bandwidth, , .
3. VU, , , . .

يمكن الحصول على معظم الرسوم البيانية باستخدام تقارير جاتلينج المستندة إلى HTML بعد الاختبار ، أو عن طريق تكوين حزمة مراقبة Graphite-InfluxDB-Grafana . للعرض ، يمكنك استخدام لوحة معلومات جاهزة من مكتبة لوحة القيادة https://grafana.com/grafana/dashboards/9935 .



عند تحليل وتجميع لوحات المعلومات الخاصة بك لـ Gatling ، ضع في اعتبارك أن النتائج في InfluxDB مخزنة مجمعة وهي مناسبة فقط للتقييم الأولي لنتائج NT. يوصى بعد الاختبار بإعادة تحميل simulation.log إلى قاعدة البيانات وإنشاء تقرير نهائي عنها والبحث عن مشاكل أداء النظام.

وصف المصفوفة للمقاييس

يتم تقديم كل ما وصفناه أعلاه على شكل قرص صغير يلخص كل هذه المعرفة.