كان إطلاقنا رهاناً محفوفاً بالمخاطر: كيف أنقذتنا اختبارات التحمل (Load Testing) من جحيم ‘هل سيصمد الخادم؟’

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

كنا قد وضعنا كل مدخراتنا وأحلامنا في هذا المشروع. موعد الإطلاق كان صباح اليوم التالي، متزامناً مع حملة تسويقية كبيرة. تخيلت السيناريو الأسوأ: آلاف المستخدمين يتدفقون على الموقع دفعة واحدة، ثم… الصمت. صفحة بيضاء، خطأ “503 Service Unavailable”، ورسائل الغضب تنهال على صفحاتنا الاجتماعية. يا خوفي من هذه اللحظة! كانت الفكرة وحدها كافية لتصيبني بالقشعريرة.

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

لماذا اختبارات التحمل ليست رفاهية بل ضرورة قصوى؟

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

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

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

رحلتنا مع اختبارات التحمل: من أين نبدأ؟

عندما قررنا البدء، كان السؤال الأول: “طيب، كيف نبدأ؟”. العملية تبدو معقدة ومخيفة في البداية، لكن يمكن تبسيطها إلى خطوات واضحة.

1. تحديد الأهداف والمسارات الحرجة

أول خطوة هي أن تسأل نفسك: ما هي أهم العمليات التي يقوم بها المستخدم في تطبيقي؟ هذه ما نسميها “المسارات الحرجة للمستخدم” (Critical User Journeys). في حالتنا (منصة التجارة الإلكترونية)، كانت المسارات كالتالي:

• تصفح الصفحة الرئيسية وقوائم المنتجات.
• البحث عن منتج معين.
• إضافة منتج إلى سلة التسوق.
• عملية تسجيل الدخول وإنشاء حساب.
• إتمام عملية الشراء (Checkout).

بعد تحديد المسارات، وضعنا أهدافاً رقمية قابلة للقياس (KPIs). مثلاً:

• زمن الاستجابة (Response Time): يجب أن تكون استجابة 95% من الطلبات (p95) أقل من 300 ميللي ثانية.
• معدل الأخطاء (Error Rate): يجب أن يكون أقل من 0.1%.
• عدد المستخدمين المتزامنين (Concurrent Users): يجب أن يتحمل النظام 2000 مستخدم متزامن في أي لحظة.

نصيحة من أبو عمر: لا تبدأ باختبار كل شيء. ركز على 2-3 من أهم المسارات التي تؤثر مباشرة على تجربة المستخدم والإيرادات. إتمام الشراء والبحث هما أهم مسارين في أي متجر إلكتروني.

2. اختيار الأداة المناسبة: k6 أم JMeter؟

هناك العديد من الأدوات في السوق، لكن أشهرها اثنان: Apache JMeter و Grafana k6. نحن جربنا الاثنين، وهذه خلاصة تجربتنا:

• Apache JMeter: الأداة المخضرمة والقوية جداً. تعتمد على واجهة رسومية (GUI) لبناء خطط الاختبار. ممتازة للسيناريوهات المعقدة جداً، لكنها تستهلك الكثير من موارد الجهاز الذي يشغلها، وكتابة الاختبارات بها قد تكون بطيئة بعض الشيء.
• Grafana k6: الأداة العصرية والمفضلة لدي شخصياً. تعتمد على كتابة الأكواد بلغة JavaScript (أو TypeScript). هذا يجعلها خفيفة جداً، سريعة، وسهلة الدمج مع أنظمة CI/CD. كونها كوداً، يمكنك تخزينها في Git ومراجعتها مثل أي كود آخر في المشروع.

قررنا استخدام k6 لسرعته وسهولة استخدامه من قبل المطورين. شعرنا أنه “يتكلم لغتنا”.

التطبيق العملي: لنكتب أول اختبار تحمل باستخدام k6

جمال k6 يكمن في بساطته. دعونا نكتب اختباراً بسيطاً يحاكي 50 مستخدماً يتصفحون الصفحة الرئيسية لموقعنا لمدة دقيقة واحدة.

أولاً، تحتاج لتثبيت k6 على جهازك (التعليمات موجودة على موقعهم الرسمي). ثم، أنشئ ملفاً باسم script.js واكتب فيه الكود التالي:

import http from 'k6/http';
import { check, sleep } from 'k6';

// 1. إعدادات الاختبار
export const options = {
  // المراحل: زيادة تدريجية للمستخدمين لمحاكاة الواقع
  stages: [
    { duration: '30s', target: 50 }, // زيادة تدريجية إلى 50 مستخدم خلال 30 ثانية
    { duration: '1m', target: 50 },  // البقاء عند 50 مستخدم لمدة دقيقة
    { duration: '10s', target: 0 },   // إنقاص المستخدمين إلى 0
  ],
  // تعريف العتبات (Thresholds) أو شروط النجاح
  thresholds: {
    'http_req_duration': ['p(95)<500'], // 95% من الطلبات يجب أن تكون أسرع من 500ms
    'http_req_failed': ['rate<0.01'],   // معدل الأخطاء يجب أن يكون أقل من 1%
  },
};

// 2. الكود الذي سينفذه كل مستخدم افتراضي
export default function () {
  // طلب GET للصفحة الرئيسية
  const res = http.get('https://your-awesome-app.com');

  // التأكد من أن الطلب نجح (status code 200)
  check(res, { 'status was 200': (r) => r.status == 200 });

  // محاكاة تفكير المستخدم: انتظار بين 1-3 ثواني قبل الطلب التالي
  sleep(Math.random() * 2 + 1);
}

لتشغيل الاختبار، افتح الطرفية (Terminal) في نفس المجلد واكتب الأمر:

k6 run script.js

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

تحليل النتائج: من الكارثة إلى النجاح

عندما أجرينا أول اختبار جدي على نظامنا، كانت النتائج كارثية! مع وصول عدد المستخدمين إلى 500 فقط (وليس 2000 كما كنا نأمل)، ارتفع زمن الاستجابة p95 إلى 8 ثوانٍ! وظهرت أخطاء بنسبة 15%. كان الخادم يختنق.

هنا تكمن القيمة الحقيقية لاختبارات التحمل. بدلاً من أن يحدث هذا يوم الإطلاق أمام آلاف المستخدمين، حدث في بيئة آمنة ومتحكم بها. بدأنا رحلة التحسين:

1. الاختبار والتحليل: أظهرت لنا أدوات مراقبة الأداء (Monitoring Tools) أن المشكلة كانت في استعلام معين لقاعدة البيانات (Database Query) كان بطيئاً جداً تحت الضغط.
2. الإصلاح والتحسين: قمنا بإضافة فهرس (Index) للجدول المسؤول عن هذا الاستعلام، وقمنا بعمل Caching لبعض البيانات التي لا تتغير كثيراً.
3. إعادة الاختبار: أعدنا تشغيل نفس اختبار التحمل مرة أخرى. هذه المرة، كانت النتائج مذهلة! صمد النظام حتى 2500 مستخدم مع الحفاظ على زمن استجابة أقل من 400 ميللي ثانية ومعدل أخطاء شبه معدوم.

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

الخلاصة والنصيحة الأخيرة 🚀

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

يا صديقي المطور، يا صاحبة المشروع، نصيحتي لكم من القلب: لا تنتظروا يوم الإطلاق لتكتشفوا نقاط ضعف نظامكم.

اختبارات التحمل ليست ترفاً، بل هي جزء لا يتجزأ من عملية تطوير البرمجيات الاحترافية. ابدأوا ببساطة، استخدموا أدوات مثل k6، واجعلوا اختبار الأداء عادة مستمرة مع كل تحديث كبير. راحة بالكم، ونجاح مشروعكم، وسمعتكم تعتمد على ذلك.