دليل شامل لاختبار التحميل (Load Testing): ضمان أداء موقعك تحت الضغط

مقدمة إلى اختبار التحميل (Load Testing)

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

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

المؤشرات الأساسية في اختبار الأداء

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

• Response time (وقت الاستجابة): هو مقدار الوقت المنقضي بين إرسال طلب واستلام الاستجابة.
• Average load time (متوسط وقت التحميل): متوسط وقت الاستجابة لجميع الطلبات.
• Peak response time (ذروة وقت الاستجابة): أطول وقت استجابة تم تسجيله خلال الاختبار.
• Throughput / Requests per second (rps) (الإنتاجية / الطلبات في الثانية): عدد الطلبات التي يتم التعامل معها في الثانية الواحدة.
• Memory / CPU utilization (استهلاك الذاكرة / المعالج): مقدار الذاكرة و/أو موارد المعالج التي تستهلكها الآلة المستضيفة للتطبيق.
• Error rate (معدل الأخطاء): نسبة الأخطاء إلى إجمالي الطلبات.
• Concurrent users (المستخدمون المتزامنون): عدد المستخدمين النشطين أو الجلسات المتزامنة في التطبيق.
• Percentiles (50% and 95%) (النسب المئوية 50% و 95%): النسبة المئوية للطلبات التي كان وقت استجابتها أفضل من قيمة معينة. على سبيل المثال، 95% يعني أن 95% من الطلبات استجابت في وقت أقل من القيمة المحددة.

أدوات عملية لاختبار التحميل

1. LoadTest: أداة بسيطة وفعالة

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

npm install -g loadtest

بعد التثبيت، كل ما تحتاجه هو فتح سطر الأوامر وتشغيل الأمر التالي:

loadtest [-n requests] [-c concurrency] URL

لغرض العرض التوضيحي، سنستخدم موقع blank.org، وهو صفحة ويب فارغة تُستخدم غالبًا لأغراض الاختبار. الأمر التالي سيرسل 60 طلبًا بـ 30 عميلًا متزامنًا:

loadtest -n 60 -c 30 https://blank.org

ملاحظة هامة: عدد المستخدمين المتزامنين (concurrent users) لا يعني عدد الطلبات المتزامنة في اللحظة نفسها. المستخدمون المتزامنون/الجلسات يمثلون عدد المستخدمين المتصلين بالتطبيق الذين يجرون طلبات على فترات منتظمة ولكن بشكل متزامن.

سيكون مخرجات الأمر السابق كما يلي:

توفر لنا هذه الأداة معلومات حول:

• النسب المئوية (percentiles) مثل 50%، 90%، 95%، 99%، و 100%.
• متوسط زمن الاستجابة (mean latency).
• معدل الأخطاء (error rate).

يمكننا أن نرى أنه بالنسبة لموقع blank.org، كان الوقت بالمللي ثانية لـ 50% من طلباتنا (30 طلبًا) أقل من 581 مللي ثانية، واستغرقت الاستجابة لأطول طلب 649 مللي ثانية.

2. Loadmill: اختبار التحميل عبر الويب

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

الخطوة التالية هي النقر على زر Run Test وتكوين عدد الجلسات المتزامنة ومدة الاختبار.

ستلاحظ أن نطاق blank.org يظهر في زر أحمر. هذا لأنه نطاق غير مُتحقق منه، وبما أننا لا نمتلك موقع blank.org، فهناك حد أقصى معين للتحميل الذي يمكننا إرساله إلى هذا الموقع. باستخدام هذا التكوين، سنرى كيف يتصرف blank.org عندما تحاول 5 جلسات متزامنة استخدام التطبيق في إطار زمني مدته دقيقتان.

كنتيجة، يمكننا رؤية الأداء بمرور الوقت:

• كان متوسط وقت الاستجابة لجميع الطلبات 55 مللي ثانية.
• كانت هناك ذروة في البداية حيث كان وقت استجابة 95% من الطلبات أقل من 1,059 مللي ثانية، و 50% من الطلبات أقل من 51 مللي ثانية.

هذا يعني أن أطول وقت للاستجابة استغرق أكثر من ثانية واحدة. في الوقت نفسه، يمكننا رؤية معدل الأخطاء والإنتاجية (throughput) بالطلبات في الثانية (rps) لجلساتنا، وهو عدد الطلبات المرسلة بواسطة مستخدمينا المتزامنين في إطار زمني مدته ثانية واحدة.

فهم الفروقات: LoadTest مقابل Loadmill

قد تتساءل الآن، لماذا هذا التباين الكبير بين نتائج الأداة الأولى وهذه الأداة؟ هنا تكمن نقطة بالغة الأهمية يجب الانتباه إليها، وهي مدى ملاءمة وصحة البيانات. يجب أن تكون واقعيًا وأن تحاول جعل اختباراتك تعكس الواقع قدر الإمكان.

هناك أكثر من استراتيجية عند إجراء اختبار الأداء. بعض الأدوات ومقدمي الخدمات يستخدمون البيئة المحلية فقط، بينما يقوم آخرون بتشغيل أجهزة افتراضية (virtual machines) لكل مستخدم متزامن.

يختلف Loadmill عن الخدمات الأخرى بسبب استخدامه لحركة مرور ويب حقيقية (real web traffic) لتوليد التحميل على الخادم المُختبر. بعبارة أخرى، تأتي حركة المرور التي تذهب إلى الموقع المستهدف من متصفحات حقيقية (real browsers). بينما ترتبط حزمة Loadtest ارتباطًا وثيقًا بالجهاز المحلي (local machine) الذي تقوم بتشغيل الاختبارات عليه، ويمكنك الذهاب إلى أقصى حد يسمح به معالج جهازك (CPU).

كما رأيت، قمت بتشغيل الاختبارات باستخدام loadtest على جهازي باستخدام سطر الأوامر (command line). كان وقت الاستجابة أكبر بعشر مرات من وقت الاستجابة باستخدام Loadmill. دعنا نكتشف السبب:

إذا فتحنا أدوات المطور (developer tools) على blank.org، يمكننا العثور على عنوان IP الخاص به، وهو 18.217.80.105. باستخدام هذه القيمة، يمكننا إجراء بحث عن IP (IP lookup) ونرى أن الخادم يقع في أوهايو، الولايات المتحدة الأمريكية. نحن نعلم أن وقت الاستجابة هو الوقت المقاس بين طلب واستجابة. لذا، ينتقل الطلب إلى الخادم ومن الخادم مرة أخرى إلى العميل (المتصفح). باستخدام الأداة الأولى، حصلنا على حوالي 500 مللي ثانية، لأنني أرسل الطلبات من جهازي. لذلك يجب أن تنتقل الطلبات ذهابًا وإيابًا ما يقرب من 11000 ميل. إذا انتقلنا إلى اللوحة الثانية من نتائج اختبارنا PERFORMANCE / COUNTRY، نرى أن جميع الطلبات أُرسلت من الولايات المتحدة الأمريكية. وهذا هو سبب وقت الاستجابة الأصغر بكثير.

تذكر عند الاختبار أنه من الأفضل محاكاة الظروف الأقرب إلى الواقع قدر الإمكان لضمان دقة البيانات. قبل الانتقال إلى الأداة التالية، أود أن أذكر شيئًا آخر عن Loadmill، وهو أنه يمكن تكوينه للقيام بأكثر من ذلك بكثير. يمكننا إنشاء سيناريوهات اختبار تحميل معقدة بطلبات متعددة تحتوي على معلمات وبيانات، بما في ذلك المصادقة الأساسية (basic authentication) وإشعارات البريد الإلكتروني (email notifications).

3. Apache JMeter: أداة قوية مفتوحة المصدر

الأداة الأخيرة في قائمتنا هي Apache JMeter، وهي تطبيق مفتوح المصدر قائم على Java لاختبار الأداء. يتطلب هذا التطبيق تثبيتًا وهو أصعب قليلاً في التكوين. لذلك، سيتم تقسيم المعلومات التالية إلى خطوات:

الخطوة 1 – التنزيل والتثبيت

قم بتنزيل أرشيف الملفات الثنائية (binaries archive) على جهاز الكمبيوتر الخاص بك وفك ضغط المحتوى. ثم، انتقل إلى مجلد bin وقم بتشغيل ملف jmeter.bat مرتين. مرة واحدة لتكوين الأداة ومرة ثانية لبدئها.

الخطوة 2 – إضافة مجموعة خيوط (Thread Group)

تحتوي مجموعة الخيوط (Thread Group) على ثلاث خصائص مهمة بشكل خاص تؤثر على اختبار التحميل:

• Number of Threads (users) (عدد الخيوط/المستخدمين): عدد الجلسات المتزامنة التي سينشئها JMeter.
• Ramp-Up Period (in seconds) (فترة التصعيد بالثواني): مدة الاختبار التي يتم خلالها زيادة عدد المستخدمين تدريجياً.
• Loop Count (عدد التكرارات): عدد مرات تنفيذ الاختبار.

الخطوة 3 – إضافة عينة طلب HTTP (HTTP Request Sampler)

في عينة طلب HTTP (HTTP Request Sampler)، ضمن قسم HTTP Request، املأ اسم الخادم (Server Name)، البروتوكول (Protocol)، والمسار (Path) للتطبيق الذي تريد اختباره.

الخطوة 4 – إضافة عرض (View)

في JMeter، ستستخدم المستمعين (listeners) لإخراج نتائج اختبار الأداء. تتوفر مجموعة متنوعة من المستمعين، ويمكنك إضافة المزيد عن طريق تثبيت الإضافات (plugins). دعنا نستخدم عرض الجدول (Table) في هذه الحالة.

الخطوة 5 – تشغيل الاختبار

شغّل الاختبار بالنقر على المثلث الأخضر.

الآن يمكننا تحليل اختبارنا. أولاً، يمكننا أن نرى في الزاوية العلوية اليمنى أن الاختبار يستمر لمدة 10 ثوانٍ، تمامًا كما حددنا في الخيارات مسبقًا. بعد ذلك، الأعمدة التي تهمنا أكثر هي Status و Latency.

• Latency (زمن الاستجابة): عدد المللي ثانية التي انقضت بين الطلب ووقت استلام الاستجابة الأولية.
• Status (الحالة): يمثل حالة الطلب، إذا كان ناجحًا أم لا. يُستخدم لحساب معدل الأخطاء.

كملاحظة جانبية، يمكننا أن نلاحظ أن القيم مشابهة لتلك التي تم الحصول عليها باستخدام loadtest. هذا لأنها تعمل بنفس الطريقة، أي من الجهاز المحلي.

المؤشرات المتبقية: استهلاك الذاكرة والمعالج

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

$ top

سيعرض لك هذا الأمر كلاً من استخدام المعالج كنسبة مئوية واستخدام الذاكرة.

أو

$ free -h

سيعرض لك هذا الأمر بيانات حول الذاكرة فقط ولكنه أسهل في القراءة.

الخلاصة

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

الخلاصة التقنية

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