تطبيقك يعمل. كل زرّ يستجيب، وكل نموذج يُرسَل بنجاح، والعرض التوضيحي أبهر مجلس الإدارة. ثم يُطلق فريق التسويق حملة، فيدخل اثنا عشر ألف مستخدم إلى صفحة الدفع خلال عشر دقائق، فينهار كل شيء: انتهاء المهلات، وأخطاء 502، وقاعدة بيانات عالقة عند استهلاك 100% من المعالج. لم تكن الشيفرة خاطئة قط؛ لكنها ببساطة لم تُسأل يومًا عن حجم الحِمل الذي تحتمله.
هذه الفجوة — بين «أنه يعمل» و«أنه يعمل تحت الضغط» — هي بالضبط مجال اختبار الأداء (Performance Testing). والهدف ليس إثبات أن نظامك سريع، بل العثور على النقطة التي يعجز عندها عن التحمّل، بشروطك أنت، في المختبر، قبل أن يكتشفها جمهور حقيقي نيابةً عنك.
ماذا يقيس اختبار الأداء فعليًا
«اختبار الأداء» مصطلح جامع، والتعامل معه كنشاط واحد هو الخطأ الأول. تحته أسئلة متمايزة:
- اختبار الحِمل (Load Testing) — هل يحافظ النظام على أزمنة استجابته عند حجم الزيارات المتوقّع في يوم مزدحم اعتيادي؟
- اختبار الإجهاد (Stress Testing) — أين نقطة الانهيار، وماذا يحدث حين تتجاوزها؟ هل يتدهور النظام بتدرّج لطيف أم ينهار دفعة واحدة؟
- اختبار الذروة المفاجئة (Spike Testing) — ماذا يحدث حين تقفز الزيارات عشرة أضعاف خلال ثلاثين ثانية، كما يحصل بعد ظهور إعلامي أو إشعار جماعي؟
- اختبار الصمود (Soak / Endurance) — شغّل النظام تحت حِمل متوسط لثماني ساعات. تسريبات الذاكرة، ونفاد تجمّع الاتصالات (connection pool)، وامتلاء قرص السجلّات لا تظهر إلا مع مرور الوقت.
- اختبار قابلية التوسّع (Scalability Testing) — حين تضاعف عدد الخوادم، هل تحصل فعلًا على ضِعف الإنتاجية، أم تحدّك قاعدة بيانات مشتركة عند 1.3 ضعف فقط؟
كل سؤال يعالج مخاطرة عمل مختلفة. اختر ما يطابق الطريقة التي يصل بها مستخدموك فعلًا.
نقطة الانهيار بيانات، لا كارثة
يعامل المهندسون لحظة انهيار النظام كأمر يجب تجنّبه. أما أنا فأعُدّها الرقم الأثمن في التمرين كله. إن لم تعرف نقطة انهيارك فأنت تخمّن سعتك — وستنتهي إما إلى توفير موارد زائدة تحرق بها المال، أو موارد ناقصة تحرق بها ثقة المستخدم.
للعثور عليها، تراقب ثلاثة أرقام بينما ترفع الحِمل تدريجيًا:
- الإنتاجية (Throughput) — عدد الطلبات في الثانية التي يعالجها النظام بنجاح.
- زمن الاستجابة عند النسب المئوية (Percentiles) — لا المتوسط. المتوسط كذبة مريحة. إن كان متوسط استجابتك 200 مللي ثانية بينما زمن p99 يبلغ 6 ثوانٍ، فإن واحدًا من كل مئة مستخدم يعيش تجربة سيئة، وعلى نطاق واسع هؤلاء آلاف.
- معدل الأخطاء (Error Rate) — لحظة ارتفاع الأخطاء، تكون قد بلغتَ منعطف المنحنى.
نقطة الانهيار ليست لحظة السقوط، بل مستوى الحِمل الذي يسبق مباشرةً ارتفاع أزمنة الاستجابة وبدء الأخطاء — وهذا هو سقف سعتك الحقيقي.
كيف تُجري اختبارًا دون أن تخدع نفسك
تقع معظم اختبارات الأداء في الأخطاء المتوقّعة نفسها. الاختبار المفيد يبدو هكذا:
- حاكِ الزيارات الحقيقية. استخرج مزيج الطلبات الفعلي من سجلّات الإنتاج. اختبارٌ يقصف نقطة نهاية واحدة رخيصة لا يخبرك بشيء؛ فالمستخدمون الحقيقيون يسجّلون الدخول، ويبحثون، ويضيفون إلى السلة، ويدفعون بنسب متداخلة.
- حدّد الأهداف قبل أن تبدأ. اضبط هدف مستوى الخدمة (SLO) سلفًا — مثلًا: «p95 أقل من 500 مللي ثانية عند 2000 مستخدم متزامن، ومعدل أخطاء دون 0.1%». بلا رقم تنجح أو تفشل عنده، أنت تنتج رسومًا بيانية فحسب.
- اختبر بيئة تشبه الإنتاج. اختبار الحِمل على حاسوب محمول، أو على خادم تجهيز ضعيف واحد، يقيس ذلك الحاسوب لا نظامك. النوع نفسه من الخوادم، وحجم البيانات نفسه، ومسار الشبكة نفسه.
- ارفع الحِمل تدريجيًا، لا دفعةً واحدة. زِد الحِمل على مراحل واثبُت عند كل مستوى. تريد أن ترى المنحنى ينحني، لا أن تعرف فقط إن نجا من ضربة واحدة.
- راقب النظام, لا مولّد الحِمل. العميل يخبرك أن الاستجابات صارت بطيئة، أما الخادم — المعالج، والذاكرة، واتصالات قاعدة البيانات، وعمق الطابور — فيخبرك بالسبب. وهذا «السبب» هو جوهر الأمر كله.
الأدوات هي الجزء الأسهل. k6 وLocust مريحان لمن يريد اختبارات مكتوبة كشيفرة؛ وGatling وJMeter يظلّان خيارين راسخين يُعوَّل عليهما. لكن الأداة أقل أهمية بكثير من نموذج الحِمل الذي تغذّيها به.
من أين تبدأ
إن لم يسبق لك قط أن اختبرت حِمل ما تشغّله في الإنتاج، فلا تُصمّم منصة اختبار ضخمة. اختر أهم رحلة مستخدم لديك — غالبًا الدفع، أو تسجيل الدخول، أو البحث — واكتب سكربتًا يقودها بنسب واقعية، وارفع الحِمل حتى ينكسر شيء. سيخبرك ذلك الرقم الأول لنقطة الانهيار عن سعتك الحقيقية أكثر مما يخبرك ربعُ سنة من التحديق في لوحات المراقبة.
ثم ضَعه في مسار التكامل المستمر (pipeline)، كي يُسقِط الانحدارُ التالي اختبارًا بدلًا من أن يُسقِط عميلًا. نقطة الانهيار ستُكتشَف في الحالتين؛ والسؤال الوحيد هو: هل تجدها أنت أولًا؟