اختبار الحمل مقابل اختبار الإجهاد
مقارنة اختبار الحمل والضغط
يقيس اختبار الحمل ، بحكم التعريف ، أداء النظام في ظل الحمل المتوقع.
في المقابل ، فإن اختبار الإجهاد يثقل كاهل النظام لإيجاد نقطة الانهيار.
فحص الاختلافات:
الحمل مقابل اختبار الإجهاد
اختبار الحمل هو اختبار مخطط لإجراء عدد محدد من الطلبات على نظام لاختبار وظائف النظام في ظل مستويات محددة من الطلبات المتزامنة. يضمن اختبار الحمل أن نظام الويب يمكنه التعامل مع الحجم المتوقع لحركة المرور ، وبالتالي يشار إليه أحيانًا باسم اختبار الحجم. الهدف من اختبار الحمل هو إثبات أن النظام يمكنه التعامل مع الحجم المتوقع بأقل قدر ممكن من التدهور المقبول في الأداء. يجب تحديد عتبة تدهور الأداء المقبول من قبل المختبرين كقيمة معينة تعتبر مقبولة للمستخدم النهائي حتى لا يرتد المستخدمون من الموقع.
اختبار الإجهاد هو اختبار مصمم لزيادة عدد الطلبات المتزامنة على نظام ما بعد النقطة التي يتدهور فيها الأداء ، حتى إلى درجة الفشل الكامل. عندما يصل اختبار الحمل (أو اختبار API ) إلى ذروته في عدد المستخدمين المتزامنين ، سيستمر اختبار الإجهاد الأساسي في زيادة الحمل على النظام حتى يتم تحميل الموارد بشكل زائد. يؤدي هذا إلى دفع النظام إلى حالة من الفشل المحتمل لمعرفة كيفية تعامل النظام معه وما إذا كان يمكن للنظام إجراء استرداد رشيق.
ضمن هذه التعريفات لاختبار الحمل واختبار التحمل ، نجد أنهما بالتأكيد ليسا مستقلين تمامًا عن بعضهما البعض. في كثير من الأحيان ، عند تشغيل الحدود العليا لاختبار الحمل ، قد ينتهي بك الأمر بشكل فعال إلى إجراء اختبار تحمّل حيث تدفع النظام إلى ما هو أبعد من حدود الموارد المتاحة. في هذه المرحلة ، قد تبدأ في رؤية إخفاقات في اختبار تحميل مماثل للإخفاقات التي تظهر عادةً عند إجراء اختبار تحمّل.
متى تختار اختبار الحمل أو اختبار الإجهاد
يتمثل أحد الاختلافات بين اختبار الحمل واختبار التحمل في أنه يمكنك إدخال فترات توقف مؤقت في اختبار الحمل لمحاكاة حركة مرور المستخدم الحقيقية. من خلال اختبار التحمل ، يمكنك تشغيل أكبر عدد ممكن من المستخدمين المتزامنين بأسرع ما يمكن لتوليد حركة مرور زائدة لإجراء اختبار تحمّل.
تختلف أهداف اختبار الحمل تمامًا مقارنة بأهداف اختبار التحمل. يتم إجراء اختبار الحمل للتأكد من أن موقع الويب أو تطبيق الويب أو واجهة برمجة التطبيقات قادرة على التعامل مع أعداد محددة من المستخدمين في وقت واحد. غالبًا ما يستخدم اختبار الحمل في عملية تخطيط السعة ، لضمان قدرة النظام على التعامل مع النمو إلى مستويات محددة من حركة المرور المتزامنة.
يستخدم اختبار الإجهاد لدفع النظام بشكل خاص إلى ما وراء قدرته المقصودة لتحديد المكونات التي تبدأ في التباطؤ ، وتحديد الاختناقات في النظام ، وتسليط الضوء على الاختناقات أو نقاط الفشل المحتملة.
يشيع استخدامها لاختبار الحمل والضغط:
إنشاء مقاييس الأداء الأساسية
يتم إجراء اختبار الحمل عادةً كسلسلة من الخطوات حيث يبدأ نظام الاختبار عددًا من المستخدمين المتزامنين المعروفين بدعمهم من قبل البنية التحتية. يؤسس هذا مجموعة أساسية من بيانات الأداء للرجوع إليها مع زيادة عدد المستخدمين المتزامنين طوال الاختبار. يمكن أن يساعد اختبار الأداء في تحديد عدة خطوط أساسية مختلفة ، مثل متوسط سرعة الاتصال ومتوسط زمن الوصول ومتوسط الوقت لتنزيل ملف بحجم ثابت والمزيد.
بمجرد معرفة قيم الأداء الأساسية ، يتم زيادة عدد المستخدمين إلى عدد يمكن توقعه بشكل واقعي لزيارة الموقع خلال فترة العينة. غالبًا ما يتم تشغيل الاختبار عند هذا العدد الثابت من المستخدمين لعدة دقائق للتحقق من استقرار موقع الويب بعد استقرار النظام عند مستوى التحميل الجديد.
من المهم أن نلاحظ أن المصطلحين اختبار خط الأساس والاختبار المعياري غالبًا ما يستخدمان بالتبادل ، ومع ذلك ، هناك اختلافات بين هذين المصطلحين. يتم إجراء اختبار الأساس لضمان عدم انخفاض أداء الموقع أو التطبيق بمرور الوقت. على سبيل المثال ، أثناء الاختبار الأساسي ، يتم تسجيل مقاييس الأداء بحيث عند تحديث هذا التطبيق أو الموقع في المستقبل ، يمكن للمهندسين اختبار ومقارنة مقاييس الأداء الجديدة مع المقاييس السابقة. ستشمل اختبارات خط الأساس هذه أيضًا أي تغييرات برمجية وبرامج وأجهزة وشبكة جديدة. الهدف هو تقديم تطبيق أو موقع متسق ، والذي بدوره يضمن تجربة إيجابية للمستخدمين.
اختبار المعيار هو ممارسة لمقارنة أداء التطبيق مقابل صناعة محددة مسبقًا أو معايير ومتطلبات تنظيمية. مثل الاختبار الأساسي ، يشمل الاختبار المعياري قياس وتسجيل أداء الأجهزة والبرامج وظروف الشبكة. يساعد اختبار المعيار على قياس جودة الخدمة لمتطلبات المؤسسة الخاصة أو مقابل المنظمات الأخرى. تساعد هذه المقاييس في إنشاء اتفاقيات مستوى الخدمة (اتفاقيات مستوى الخدمة) للمؤسسات وتوفر مستوى خدمة مضمونًا للمستخدمين أو العملاء. اقرأ المزيد عن اختبار الأساس والمعيار .
يتمثل أحد الاختلافات بين إنشاء مقياس أداء أساسي أثناء اختبار الحمل واختبار الإجهاد في أن الفرق بين خط الأساس وأداء الذروة سيساعد في تحديد ما إذا كان لديك الأنظمة المناسبة للتعامل مع ذروة الحمل ، بينما أثناء اختبار الإجهاد أنت أكثر تشعر بالقلق إزاء النقطة التي يصبح فيها النظام متوترًا ، أو حتى يتوقف عن العمل بشكل صحيح.
اختبار التحميل أو الإجهاد لتحديد معوقات تطبيقات الويب
تعمل التطبيقات المستندة إلى الويب عادةً في مستعرض وعندما تتم برمجتها بشكل صحيح ، نظرًا لطبيعتها غير المتزامنة ، قد تتعامل مع مئات أو آلاف المستخدمين المتزامنين. إذا كنت تقوم بتوليد حمل متوقع في حدود سعة نظامك ، فيجب أن تظل أوقات استجابة التطبيق ضمن الإرشادات التي تم إنشاؤها. إذا قمت بدفع النظام إلى ما وراء هذه الحدود ، فإنك تنتقل إلى مجال اختبار الإجهاد ، مما يتسبب عن قصد في إجهاد النظام لتحديد المكونات التي تفشل (يتم تنفيذ ذلك غالبًا باستخدام أدوات مفتوحة المصدر مثل JMeter ). لذلك ، فإن أي اختبار يتم إجراؤه بغرض تحديد الاختناقات يعتبر عادةً اختبار إجهاد (والذي يختلف عن اختبار API ومراقبة API ).
اختبار الحمل لإنشاء اتفاقيات مستوى الخدمة (SLAs)
من الأفضل إجراء اختبارات التحميل في بيئة الإنتاج لفهم متوسط أوقات الاستجابة تحت الحمل المتوقع للمستخدم. تصبح أوقات الاستجابة المتوسطة هذه هي الأساس لاتفاقيات مستوى الخدمة المقبولة. من هنا ، الأمر متروك لك لتحديد عتبات إضافية تعتبر غير مقبولة بموجب اتفاقيات مستوى الخدمة الخاصة بك من حيث الأداء المتوقع لعملائك.
اختبار الحمل لتخطيط السعة
يمكن أن يساعد توليد الحمل المتزايد على تطبيق الويب في التنبؤ بأداء التطبيق لحمل مستخدم أثقل في المستقبل. إذا كان التطبيق يستجيب ضمن معلمات SLA الخاصة بك ، فسيتم اعتبار هذا الاختبار مكونًا ناجحًا في تخطيط السعة. إذا كانت مقاييس الأداء المسجلة أثناء الاختبار خارج المعلمات المرغوبة ، فقد يصبح اختبار الحمل بمثابة اختبار ضغط بينما تدفع النظام إلى ما هو أبعد من سعته المتاحة.
البنية التحتية لتطبيقات الويب الخاصة باختبار الإجهاد
يعد تحديد النقطة التي يفشل فيها كل مكون في البنية التحتية الخاصة بك جزءًا مهمًا من الحفاظ على تطبيق ويب قابل للتطوير. يتيح لك اختبار الإجهاد الفعال عزل كل مكون من خلال سلسلة من الاختبارات المختلفة لتحديد نقطة فشل هذا المكون. قد تشمل هذه الاختبارات:
- عزل كل حركة المرور إلى منطقة جغرافية معينة.
- الحد بشكل مصطنع من مساحة القرص المتوفرة.
- بشكل متكرر إرسال طلب GET كبير بشكل خاص.
- تحديد الحد الأقصى لعدد اتصالات البيانات.
- تنزيل ملف صورة كبير.
- مرارًا وتكرارًا إرسال POST مكثف يكتب بكثافة إلى قاعدة بيانات.
تم تصميم كل اختبار للتأكيد على مكون معين للبنية التحتية لتحديد نقاط الفشل ومعدل الفشل والحدود العليا لقدرة النظام. يمكن أن تساعد اختبارات الإجهاد في تحديد الاختناقات أثناء الأحمال الشديدة القصيرة من أشياء مثل التسويق الفيروسي ، والتعرف على الأخبار الدولية ، وأيام التسوق عبر الإنترنت الثقيلة مثل الجمعة السوداء.
الاختلافات بين اختبار الحمل واختبار الإجهاد
عادةً ما يؤدي اختبار الإجهاد إلى الحد الأقصى لجزء واحد من النظام أو جزء آخر مما يؤدي في النهاية إلى حدوث تباطؤ ثم تعطل أو عدم استجابة. من المهم تحديد المكونات في النظام التي ستكون أول من يواجه مشكلات أثناء الاختبار. لهذا السبب ، هناك العديد من المكونات التي نوصي بمراقبتها عند إجراء اختبار التحمل. تجدر الإشارة إلى أنه بناءً على التطبيق أو البرنامج أو حتى التكنولوجيا المستخدمة في بيئتك / نظامك ، قد تختلف المقاييس التي تقيسها أثناء اختبار الإجهاد. ومع ذلك ، فإن القائمة التالية شركات
- أوقات الاستجابة . الوقت المستغرق لتلقي رد بعد إرسال الطلب. هذا مهم بشكل خاص لقياس أوقات الاستجابة كما يراها المستخدمون
- قيود الأجهزة . وهذا يشمل مراقبة استخدام وحدة المعالجة المركزية ، وذاكرة الوصول العشوائي ، والقرص I / O. إذا تأخرت أوقات الاستجابة أو كانت بطيئة ، فقد تكون مكونات الأجهزة هذه من الجناة المحتملين.
- الإنتاجية . مقدار البيانات التي يتم إرسالها / تلقيها خلال مدة الاختبار بناءً على مستويات النطاق الترددي لديك.
- قاعدة البيانات تقرأ وتكتب . إذا كان تطبيقك يستخدم أنظمة متعددة ، يمكن أن تشير اختبارات الإجهاد إلى النظام أو الوحدة التي تشكل عنق الزجاجة.
- افتح اتصالات قاعدة البيانات . يمكن لقواعد البيانات الكبيرة أن تؤثر بشدة على الأداء ، مما يؤدي إلى إبطاء أوقات الاستجابة.
- محتوى الطرف الثالث . تعتمد صفحات الويب والتطبيقات على العديد من مكونات الجهات الخارجية. سيوضح لك اختبار الإجهاد أي منها قد يؤثر على صفحتك أو أداء التطبيق.
إذا لم يكن لديك أنظمة مراقبة كافية مطبقة على جانب الخادم ، فإن منصة Dotcom-Monitor توفر حلاً لمراقبة عداد الأداء لمراقبة أداء الخادم بشكل كامل. يتم تثبيت عدادات الأداء هذه مباشرة على الخوادم الخاصة بك لمراقبة عدادات أداء Windows أو Linux أو SNMP (بروتوكول إدارة الشبكة البسيط). بالإضافة إلى ذلك ، هناك أيضًا حل لمراقبة أي عدادات أداء مخصصة من أجهزتك وخوادمك. لمزيد من المعلومات حول مراقبة عداد الأداء ، تفضل بزيارة صفحة حلول مراقبة عداد الأداء.
يمكن إظهار المشكلات المتعلقة بأي من هذه العناصر على النحو التالي:
- استجابة بطيئة للحزمة الأولى.
- تأخيرات كبيرة بين طلبات GET / POST والاستجابات.
- أطول من أوقات تحميل الصفحة العادية.
- انتهاء مهلة تحميل صفحة الويب.
- تم إرجاع رموز خطأ الخادم.
بينما قد يتم اكتشاف هذه المشكلات نفسها في البداية أثناء اختبار الحمل ، فإن الفكرة وراء اختبار الحمل هي محاكاة الأحمال المتوقعة التي يجب أن يكون النظام قادرًا على التعامل معها بشكل منتظم. في بعض الأحيان قد يكون هذا هو الحال حيث يواجه النظام لفترة وجيزة تباطؤًا أثناء تخصيص الموارد للحمل المتزايد ، ولكن في معظم الحالات ، يجب أن يكون النظام قادرًا على التعافي من التخصيص الأولي واستئناف الأداء الطبيعي في ظل اختبار الحمل.
إذا استمر اختبار الحمل في اكتشاف المشكلات ، فأنت بحاجة إلى إلقاء نظرة فاحصة على عدادات أداء النظام لتحديد السبب الجذري للتباطؤ أو الفشل. يحدث هذا عندما يصبح اختبار الحمل بمثابة اختبار إجهاد حيث يتسبب الحمل بشكل غير متوقع في حدوث مشكلات في الأداء. اتصل بفريقنا للحصول على عرض توضيحي لمنصة LoadView. سيرشدك مهندس الأداء خلال عملية اختبار الحمل والتحمل بأكملها. بدءًا من إظهار كيفية إنشاء البرامج النصية لصفحة الويب أو سيناريوهات تطبيق الويب ، إلى تكوين الاختبار وبدء تشغيله ، سيأخذونك خلال العملية بأكملها والإجابة على أي أسئلة قد تكون لديك على طول الطريق.
لا توجد بطاقة ائتمان. لا التزام. ادفع كما تذهب.