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

ما هي جوانب الأداء التي نهتم بها؟

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

• السرعة: ما مدى سرعة تحميل الصفحة؟ بالنسبة للسرعة، قد تنظر في الوقت المستغرق لعرض الصفحة (rendering time) أو في أوقات استجابة واجهات برمجة التطبيقات (API) أو مُعدّل نقل البيانات لعمليات نقل ملفات أكبر.
• الاستقرار (Stability): هل يتصرّف النظام بشكل طبيعي؟ من أجل الاستقرار سوف تنظر في معدّلات الخطأ.
• قابلية التوسّع (Scalability): ما هي الموارد (resources) التي نحتاج إلى زيادتها وبأي مقدار إذا تضاعف عدد مستخدمينا؟ لقابلية التوسّع سوف تنظر في استخدام الموارد بالمقارنة مع الأحمال المختلفة (different loads).

ما هي الموارد التي قد تُكوّن اختناقات (Bottlenecks)؟

إذا كنت تريد العثور على اختناقات في خدمات الويب، قُم بإلقاء النظرة على:

• الحِمْل على قاعدة البيانات (Database Load): هل حجم الطلبات (requests) التي نرسلها إلى قاعدة البيانات معقول؟ هل الطلبات نفسها سريعة التنفيذ؟
• ذروة استخدام الذاكرة (Peak Memory Usage): هل هناك أي شيء ثقيل تحتاج إلى حسابه؟
• الأجهزة (Hardware): لقد سمعنا عن حالات كانت فيها بطاقة الشبكة (network card) عاملاً مُقيّدًا، على الرغم من أن هذا قد يكون مشكلة أقل مع الأجهزة المستضافة على السحابة الإلكترونية.
• وحدة المعالجة المركزية (CPU): عندما يكون استخدام وحدة المعالجة المركزية مرتفعًا جدًا فسوف يتفكّك كل شيء.
• مساحة القرص: قد تؤدي ملفات السجِل (log files) أو الملفات التي تم إنشاؤها إلى إنهاء الخدمة على فترات تشغيل أطول.
• الاتصالات (Connections): قد يكون هناك حد أقصى لعدد اتصالات HTTP/اتصالات قاعدة البيانات. بالنسبة لـ Postgres، يكون الحد الأقصى للاتصالات هو 100. ويقتصر الذين يعملون على nginx عادةً على 500 اتصال متزامن (مصدر/source).

أنواع اختبار الأداء

• اختبار الحِمْل (Load Testing)

الغرض من اختبار الحِمْل هو معرفة سلوك النظام الذي تم اختباره في ظل الحِمْل المتوقّع. لا تريد كسر النظام هنا، ولكنك تريد أن يكون لديك حِمْل قد تحصل عليه خلال ساعات الذروة. هل التطبيق قادر على الأداء كما هو متوقّع في ظل الحِمْل المتوقّع؟

• اختبار الضغط (Stress Testing)

بعد اختبار الحِمْل، نعرف كيف يتصرّف النظام في ظل الحِمْل المتوقّع. دعونا نجعل الأشياء تسقط. عندما نختبر التطبيق تحت عبء شديد لمعرفة متى / أين / كيف تسقط الأشياء، فإننا نسمّيه اختبار الضغط.

هل النظام مستقر تحت الحِمْل؟ هل يرى المستخدمون إخفاقات؟ أين هو الحد الأعلى للنظام؟ أين حدود النظام؟ هل يتعافى النظام بعد الفشل؟ عندما يفشل، هل يتأثر فقط توافر الأنظمة (availability) أم تتأثر صحّتها (correctness) أيضًا؟

• اختبار التجريب لفترات طويلة (Soak Testing)

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

الأشياء التي يمكن أن تسوء ويتم اكتشافها تحت هذا الاختبار:

1. استنفاذ الاتصال مع قاعدة البيانات
2. إعادة التشغيل غير المتوقعة
3. تسرّب الموارد على سبيل المثال تسريبات الذاكرة
4. السجلات أو الملفات الأخرى التي تؤدي إلى تضخّم النظام

بالتوفيق للجميع…

* المصدر: https://levelup.gitconnected.com/performance-testing-for-web-services-b51fffa3bd24

** الصورة من موقع: https://www.kualitatem.com/performance-testing