اختبار الذروة المفاجئة

لماذا يهم

اختبار الإجهاد، كما في الدرس السابق، يدفع الحمل إلى ما بعد الذروة المتوقعة ليجد الحد الأقصى. أما اختبار الذروة المفاجئة فيسأل سؤالاً آخر: قد تكون الذروة ضمن ما يتحمله النظام بعد أن يتوسع، لكنها تصل أسرع مما يستطيع النظام أن يتفاعل. فالمثيلات (Instances) الجديدة تحتاج دقائق لتبدأ، وذاكرة التخزين المؤقت باردة، ومجمّعات الاتصالات (Connection Pools) مُعدّة للحركة المعتادة، وكل طلب لا يمكن خدمته بعد ينتظر في قائمة انتظار (Queue) أو يفشل.

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

شكل ملف الذروة المفاجئة

لملف الذروة (Spike Profile) خمس مراحل: خط أساس عند الحمل المعتاد، ثم صعود يُقاس بالثواني لا بالدقائق، ثم ثبات قصير عند مستوى الذروة، ثم هبوط سريع، ثم فترة تعافٍ عند خط الأساس. وفترة التعافي جزء من الاختبار، لأنها تكشف هل يعود النظام إلى وضعه الطبيعي. وخذ مستوى الذروة ومدتها من الحدث الحقيقي، مثل الجمهور المتوقع لحملة أو تخفيضات العام الماضي، لا من رقم مستدير. ويرسم دليل أنواع الاختبار في Grafana k6 الذروة دون ثبات أو بثبات قصير جداً؛ فإذا كان الاندفاع الحقيقي يدوم دقائق، كما في التخفيضات الخاطفة، فأبقِ الذروة طوال تلك المدة.

قُد الحمل بمعدل الوصول (Arrival Rate)، لا بعدد ثابت من المستخدمين الافتراضيين (Virtual Users). ففي هذا النموذج المغلق ينتظر كل مستخدم افتراضي استجابته قبل أن يرسل الطلب التالي، فإذا تباطأ النظام أرسلت الأداة طلبات أقل وأخفت الاندفاع نفسه الذي تريد اختباره. ويستخدم السكربت أدناه منفّذاً (Executor) يعتمد معدل الوصول؛ وإذا نفد من k6 المستخدمون الافتراضيون اللازمون للحفاظ على المعدل أبلغ عن dropped_iterations، أي أن الأداة هي التي قصّرت لا النظام.

import http from 'k6/http';

export const options = {
  scenarios: {
    flash_sale_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 100,          // requests per second (one request per iteration)
      timeUnit: '1s',
      preAllocatedVUs: 500,
      maxVUs: 6000,            // enough to keep the rate when responses slow down
      stages: [
        { duration: '5m', target: 100 },   // 1 baseline
        { duration: '30s', target: 600 },  // 2 spike up
        { duration: '5m', target: 600 },   // 3 hold
        { duration: '30s', target: 100 },  // 4 drop
        { duration: '10m', target: 100 },  // 5 recovery
      ],
    },
  },
};

export default function () {
  http.get('https://staging.example.com/api/checkout/summary');
}

جرّبها: مولّد بيانات اختبار الأداء جرّبها: مولّد اختبارات الطلبات المتزامنة

التوسع التلقائي وتأخر التوسع

يضيف التوسع التلقائي (Autoscaling) مثيلات عندما يتجاوز مقياسٌ ما عتبة محددة، وكل خطوة في ذلك تستغرق وقتاً: يُحسب متوسط المقياس على نافذة زمنية، وتُقيَّم القاعدة وفق جدول زمني، ثم يجب أن يُقلع المثيل الجديد ويُهيّأ ويجتاز فحص السلامة (Health Check) قبل أن يرسل إليه موازن الحمل (Load Balancer) أي حركة. مجموع ذلك هو تأخر التوسع (Scaling Lag)، وحتى ينتهي تحمل المثيلات الموجودة الاندفاع كله. لذلك يقيس اختبار الذروة المفاجئة سلسلة التوسع كاملة، لا عدد المثيلات النهائي فقط:

• الزمن من بداية الذروة إلى قرار التوسع، ومن القرار إلى بدء المثيلات الجديدة في خدمة الحركة.
• الحد الأقصى لعدد المثيلات، وهل تبلغه الذروة.
• ما لا يتوسع مع التطبيق: اتصالات قاعدة البيانات (فكل مثيل جديد يفتح مجمّعه الخاص)، وحدود معدل الطلبات لدى الأطراف الخارجية، وخادم تخزين مؤقت وحيد.
• التقليص (Scale-in) بعد ذلك: مدة فترة التهدئة (Cooldown)، وهل يتذبذب عدد المثيلات صعوداً وهبوطاً حين يحوم الحمل قرب العتبة.

قوائم الانتظار والحمل الزائد والتعافي

حين تصل الطلبات أسرع مما تُخدم، ينتظر الفرق في قائمة انتظار: في موازن الحمل أو خادم الويب أو مجمّع الاتصالات أو وسيط الرسائل (Message Broker). فعند ⁦600⁩ طلب في الثانية مقابل سعة ⁦400⁩، تزيد الطلبات المتراكمة (Backlog) بمقدار ⁦200⁩ كل ثانية؛ وبعد ⁦30⁩ ثانية ينتظر ⁦6,000⁩ طلب، وينتظر كل طلب جديد نحو ⁦15⁩ ثانية خلفها. وحين ينتهي الاندفاع لا تُصرَّف الطلبات المتراكمة إلا بقدر السعة الفائضة، وزمن التصريف هذا جزء من التعافي.

النظام الذي يتعامل جيداً مع الحمل الزائد يُبقي قوائم انتظاره قصيرة ويرفض ما لا يستطيع خدمته في الوقت المناسب، بالرمز 503 Service Unavailable الذي يعرّفه RFC 9110 لحالة الحمل الزائد المؤقت ويمكن أن يرافقه الترويسة Retry-After، أو بالرمز 429 Too Many Requests (المعرَّف في RFC 6585) عند تجاوز حدّ عميل بعينه، بدلاً من ترك الطلبات تنتظر حتى تنتهي مهلة العملاء. وإعادة المحاولة تزيد الذروة سوءاً: فالعملاء الذين يعيدون المحاولة فوراً يضاعفون الحمل، لذا تأكد من أنهم يستخدمون التراجع الأسي مع تأخير عشوائي (Exponential Backoff with Jitter)، وحاكِ هذا السلوك في السكربت.

• في كل دقيقة من الذروة: معدل الأخطاء ونوعها (فالرمز 503 السريع استجابة مصممة، أما مهلات 504 وأخطاء 500 فلا)، وزمن الاستجابة عند p95 وp99، وهل يظل الدفع يعمل بينما تُرفض الطلبات الأقل أهمية.
• قوائم الرسائل: أقصى عمق وزمن التصريف، دون فقدان أي رسالة أو معالجتها مرتين، ودون طلبات شراء مكررة حين يعيد عميل إرسال طلب كان قد نجح فعلاً.
• التعافي: الزمن حتى يعود زمن الاستجابة والأخطاء وعمق قوائم الانتظار وعدد المثيلات إلى خط الأساس، دون أن يبقى شيء عالقاً.

جرّبها: محاكي رموز حالة API جرّبها: مرجع رموز حالة HTTP

مثال تطبيقي: تخفيضات خاطفة في الساعة ⁦20:00⁩

بيئة ما قبل الإنتاج (Staging) مماثلة لبيئة الإنتاج في الحجم: ⁦4⁩ مثيلات يخدم كل منها نحو ⁦100⁩ طلب في الثانية، خلف بوابة (Gateway) تنهي مهلة الطلب بعد ⁦10⁩ ثوانٍ. وفي كل دقيقة تفحص أداة التوسع التلقائي (Autoscaler) متوسط استهلاك المعالج (CPU) في الدقيقة الأخيرة؛ فإذا تجاوز ⁦70%⁩ أضافت ⁦4⁩ مثيلات، بحد أقصى ⁦8⁩ مثيلات، تحتاج نحو دقيقتين لتجهز، ثم تزيلها بعد ⁦5⁩ دقائق تحت ⁦30%⁩. ولكل مثيل ⁦20⁩ اتصالاً بقاعدة البيانات، وقاعدة البيانات تقبل ⁦150⁩ اتصالاً. يشغّل المختبِر ملف الحمل من السكربت أعلاه عبر رحلة الدفع التي تُنشئ طلبات شراء تجريبية، بـ⁦5,000⁩ مستخدم اختبار مختلف، ويلخّص النتائج المقيسة دقيقة بدقيقة حسب المراحل:

• تأخر التوسع: بدأت الذروة عند ⁦05:00⁩ ولم تخدم المثيلات الجديدة الحركة إلا عند ⁦08:00⁩. وفي هذه الأثناء كان يصل نحو ⁦600⁩ طلب في الثانية مقابل سعة ⁦400⁩: فتراكمت الطلبات حتى بلغت مهلة البوابة البالغة ⁦10⁩ ثوانٍ، واستقر p95 عند ⁦10⁩ ثوانٍ، ومنذ ⁦06:00⁩ فشل ثلث الطلبات. وموعد التخفيضات معروف مسبقاً، فيستطيع الفريق التوسع قبل أن تبدأ.
• حدّ خفي: ⁦8 × 20 = 160⁩ اتصالاً، لكن قاعدة البيانات تقبل ⁦150⁩، فأحدث التوسع أخطاء جديدة. سجّله عيباً مع هذا الحساب.
• لا رفض للحمل الزائد (Load Shedding): انتظرت الطلبات حتى مهلة البوابة البالغة ⁦10⁩ ثوانٍ بدلاً من أن تُرفض فوراً بالرمز 503 مع Retry-After. فمع وصول ⁦600⁩ طلب وخدمة ⁦400⁩ لم يكن ممكناً خدمة الثلث في الحالتين، ورفضه فوراً كان سيُبقي قائمة الانتظار قصيرة والثلثين الآخرين سريعين.
• التعافي: صُرّفت الطلبات المتراكمة بعد نحو ⁦30⁩ ثانية من وصول المثيلات الجديدة، وعاد زمن الاستجابة إلى خط الأساس فور هبوط الحمل، لكن قائمة رسائل البريد التي تؤكد الطلبات، والتي لا يتوسع عمّالها، بلغت ذروتها عند ⁦9,000⁩ رسالة ولم تفرغ إلا عند ⁦17:00⁩، بعد ست دقائق من الهبوط. اسأل هل هذا التأخير مقبول، وأعد تشغيل الملف نفسه بعد كل إصلاح.

Spike test, run 1 (staging sized like production)

time   arrival     instances  p95     errors  observation
00-05  100/s       4          220 ms  0%      baseline
05-06  up to 600   4          10 s    5%      CPU 100%, backlog builds, first 504 at 05:54
06:00                                         scale-out triggered: +4 instances
06-08  600/s       4          10 s    33%     504 from the gateway (10 s timeout)
08:00                                         4 new instances in service (maximum 8)
08-09  600/s       8          8.9 s   6%      backlog drains in about 30 s
09-11  600 to 100  8          450 ms  5%      DB: too many connections (160 > 150)
11-16  100/s       8          210 ms  0%      API at baseline; email queue peaks at 9,000
16-21  100/s       4          230 ms  0%      scale-in 16:00; email queue empty at 17:00

جرّبها: مولّد بيانات اختبار التحميل

أسئلة شائعة

المراجع

• Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
• Load test types — Grafana k6 documentationGrafana Labsتعريفات أنواع اختبار الحمل الشائعة — الاختبار الدخاني والحمل المتوسط والإجهاد والتحمّل الطويل (Soak) والذروة المفاجئة (Spike) ونقطة الانكسار — وما يُراد من كلٍّ منها كشفه.
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016أهداف مستوى الخدمة وميزانيات الخطأ ومراقبة «الإشارات الذهبية الأربع» والتعامل مع الحمل الزائد — الجانب التشغيلي للمرونة.
• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.