ما هو اختبار الأداء؟

أنواع الاختبارات. مالك المنتج، «سريع» و«لا ينهار في اليوم الأول»: اختبار حمل عند الذروة المتوقعة، أي 100 طلب في الثانية بمزيج رحلات الذروة، للتأكد من تحقيق أهداف زمن الاستجابة والأخطاء؛ ثم اختبار إجهاد يواصل رفع الحمل إلى ما بعد الذروة لإيجاد الحد ومعرفة ما إذا كان النظام يفشل فشلاً رشيقاً (إجابات أبطأ، ورد سريع يطلب المحاولة لاحقاً مثل 503) أم كارثياً (انهيارات، أو تسجيلات تضيع أو تتكرر). مسؤول القبول والتسجيل، «غير صالحة للاستخدام في الساعة الأولى»: اختبار الذروة المفاجئة، أي قفزة من حركة شبه معدومة إلى الذروة وما بعدها خلال دقيقة كما يحدث في الثامنة، لفحص قوائم الانتظار والتعافي. وفي الثامنة يحدّث الطلاب الصفحة بدلاً من التفكير، فيرسل العدد نفسه من الطلاب طلبات أكثر؛ لذا نمذج الذروة بوقت تفكير أقصر أو بمعدل طلبات أعلى. قائد فريق العمليات، «يزداد بطئاً»: اختبار التحمّل بحمل يوم عادي لساعات طويلة، ويُفضَّل لأيام، مع مراقبة الذاكرة والاتصالات والقرص بحثاً عن تسرّب. معماري النظام: اختبار قابلية التوسع، أي خطوات الحمل نفسها بخادم تطبيق واحد ثم بخادمين؛ فالمقارنة وحدها تبيّن هل ترتفع الإنتاجية مع الخادم الثاني. المطوّر: قياس الأداء المرجعي، أي قياس سريع قابل للتكرار لنقطة نهاية توفّر المقاعد في البناء القديم والجديد بالبيانات والبيئة نفسيهما، مع مقارنة p50 وp95. والترتيب المعقول: خط الأساس بمستخدم واحد وقياس الأداء المرجعي أولاً، ثم اختبار الحمل، ثم الإجهاد والذروة المفاجئة، ثم مقارنة قابلية التوسع واختبار التحمّل، مع إعادة اختبار الحمل بعد كل إصلاح.

أهداف قابلة للقياس. هذه مقترحات تتفق عليها مع مالك المنتج، وبعد الاتفاق تصبح معايير الخروج لاختبارات الأداء. الذروة: بمزيج الذروة (البحث عن المقررات 60%، وعرض شعبة 25%، والتسجيل في شعبة 10%، وتسجيل الدخول 5%) وبمعدل 100 طلب في الثانية يستمر 30 دقيقة بعد تصاعد مدته 10 دقائق في بيئة Staging بحجم الإنتاج، يكون p95 أقل من 800 مللي ثانية وp99 أقل من ثانيتين لكل رحلة، وتفشل أقل من 0.1% من الطلبات، ولا يضيع أي تسجيل ولا يتكرر. الهامش: تبقى الأهداف نفسها متحققة عند 150 طلباً في الثانية (تشرح الخطوة الثالثة سبب اختيار 50%). الذروة المفاجئة عند الفتح: من حركة شبه معدومة إلى 150 طلباً في الثانية خلال دقيقة واحدة، ويستمر ذلك 15 دقيقة، فلا ينهار شيء ولا يضيع تسجيل ولا يتكرر؛ والطلبات التي لا يستطيع النظام خدمتها تتلقى رداً سريعاً واضحاً بدلاً من أن تبقى معلّقة؛ ويعود p95 إلى أقل من 800 مللي ثانية خلال 5 دقائق بعد أن ينخفض الحمل إلى 100 طلب في الثانية. الأسابيع الثلاثة: بمعدل 15 طلباً في الثانية مدة 48 ساعة على الأقل، لا يزيد p95 في النهاية على p95 في الساعة الأولى بأكثر من 10%، وتبقى الذاكرة واتصالات قاعدة البيانات ثابتة، ولا يحتاج شيء إلى إعادة تشغيل. وقد كان النظام القديم يتدهور على مدى أيام، فاختبار تحمّل أقصر لا يثبت شيئاً يُذكر ما لم تراقب هذه الاتجاهات. قد تختلف أرقامك، لكن كل هدف يجب أن يحدد الرحلة والحمل والمئين ومعدل الأخطاء والمدة والبيئة؛ أما «سريع» و«لا ينهار» فلا يحددان شيئاً منها.

المستخدمون الافتراضيون. ينتظر كل مستخدم افتراضي الاستجابة ثم «يفكّر» قبل طلبه التالي، لذا يعطي قانون ليتل (Little’s law): المستخدمون الافتراضيون ≈ الطلبات في الثانية × (متوسط زمن الاستجابة + متوسط وقت التفكير) = ⁦100 × (0.5 + 7.5) = 800⁩. أما ضرب الطلبات في زمن الاستجابة وحده (⁦100 × 0.5 = 50⁩) فلا يعدّ إلا الطلبات الجارية في اللحظة نفسها، ويولّد حملاً أقل بكثير من المطلوب. ومع هامش ⁦20–50%⁩ يصبح العدد من 960 إلى 1,200 مستخدم افتراضي، أي نحو 120 إلى 150 طلباً في الثانية. اختر الحد الأعلى هنا: فرقم 100 طلب في الثانية هو ما عالجه النظام القديم وهو مُثقَل، لا الطلب الحقيقي؛ فالطلبات التي رُفضت قبل أن تصل إليه لا تظهر في سجلاته، والطلاب الذين يئسوا عادوا لاحقاً. تعامل مع هذا الرقم كحد أدنى، واسأل هل سجّل خادم الويب طلبات مرفوضة أو منتهية المهلة عند الثامنة. وإن أدخلت 800 مستخدم ووقت تفكير ثابتاً قدره 7,500 مللي ثانية في مولّد بيانات اختبار الأداء، فسيقدّر نحو 104 طلبات في الثانية، أي أكثر قليلاً من 100، لأنه يفترض نحو 200 مللي ثانية لكل استجابة بدلاً من 0.5 ثانية.

مسودة الخطة. (1) مولّد الحمل على الخادم قيد الاختبار ينافسه على المعالج والذاكرة والشبكة، فيبدو النظام أبطأ مما هو عليه، وقد يصبح المولّد نفسه هو الحد: شغّل k6 على أجهزة منفصلة وراقب معالجاتها أيضاً. (2) حساب واحد لكل المستخدمين يعني أن بيانات الطالب نفسه تأتي من الذاكرة المؤقتة، وأن كل تسجيل يصيب سجل الطالب نفسه، فتبدو القراءات أسرع مما هي في الإنتاج، وتتصادم التسجيلات بطريقة لا يُنتجها أي يوم حقيقي (لا يستطيع طالب أن يسجّل في الشعبة نفسها مرتين): ولّد آلاف الطلاب الاختباريين المختلفين، ويُفضَّل بعدد من سيسجّلون، في مجموعة بيانات CSV، ووزّع التسجيلات على شعب كثيرة. (3) بدء 1,200 مستخدم في الثانية نفسها ذروة مفاجئة لا اختبار حمل، وإخفاقه لا يخبرك شيئاً عن الذروة المتوقعة: صعّد الحمل خلال نحو 10 دقائق، وحافظ على الحالة المستقرة 30 دقيقة، ثم اخفضه تدريجياً، واختبر الذروة المفاجئة منفصلةً بهدفها الخاص بعد نجاح اختبار الحمل. (4) المتوسط يخفي الذيل البطيء، و«أقل من ثانية» لم يتفق عليه أحد، والأخطاء لا تُفحص أصلاً: أبلغ عن p50 وp95 وp99 لكل رحلة مع الإنتاجية ومعدل الأخطاء، مقابل الأهداف المتفق عليها. (5) بيانات 300 طالب و40 شعبة تتسع لها الذاكرة وتجعل كل استعلام سريعاً، ومنها استعلام توفّر المقاعد الجديد الذي سأل عنه المطوّر: استخدم بيانات بحجم الإنتاج، بعدد الطلاب والمقررات والشعب نفسه، مولَّدة أو منسوخة من الإنتاج بعد إزالة هويات الطلاب. وما ينقص الخطة: خط أساس بمستخدم واحد قبل الحمل، ثم الحمل على خطوات؛ ومزيج الرحلات ووقت التفكير البالغ 7.5 ثانية؛ ومراقبة جهة الخادم أثناء التشغيل (معالج خادم التطبيق وذاكرته، ومعالج قاعدة البيانات، ومجمّع الاتصالات، والاستعلامات البطيئة)؛ وتشغيل ثانٍ للتأكد من أن النتيجة قابلة لإعادة الإنتاج؛ وأهداف متفق عليها مع مالك المنتج.

قراءة النتائج. افحص عبء العمل أولاً: أنتج 800 مستخدم افتراضي 102 طلب في الثانية، كما توقعت الصيغة. وعند الذروة (الخطوة 3) تتحقق أهداف زمن الاستجابة والأخطاء لجميع الطلبات معاً: إذ يبلغ p95 نحو 480 مللي ثانية، وp99 نحو 950 مللي ثانية، والأخطاء 0.04%. لكن الجدول لا يعرض كل رحلة على حدة، وبحصة 10% قد يكون p95 للتسجيل في شعبة أبطأ بكثير بينما يبقى p95 الإجمالي منخفضاً؛ كما أن الخطوة استمرت 10 دقائق لا 30 دقيقة كما يطلب الهدف. لذا اطلب p95 لكل رحلة، وشغّل اختبار الحمل الكامل مدة 30 دقيقة، قبل أن تعلن تحقق هدف الذروة. أما هدف الهامش فلم يتحقق. فمن الخطوة 3 إلى الخطوة 4 أضاف 200 مستخدم إضافي 3 طلبات في الثانية فقط (من 102 إلى 105) بينما تتوقع الصيغة نحو 125، وفي الوقت نفسه قفز p50 من 220 إلى 1,500 مللي ثانية، وp95 إلى 4,100 مللي ثانية، والأخطاء إلى 1.2%. وارتفاع زمن الاستجابة مع ثبات الإنتاجية يعني بلوغ عنق زجاجة: هذا البناء يتوقف عند نحو 105 طلبات في الثانية، أي أعلى من ذروة الفصل الماضي المسجَّلة بـ 5% فقط، وأقل بكثير من 150 طلباً في الثانية التي يطلبها هدف الهامش.

عنق الزجاجة المرجّح في جهة قاعدة البيانات، لا في معالج خادم التطبيق. فالمعالج يبقى قرابة 75% ويتبع الإنتاجية، بينما تبلغ ذروة اتصالات قاعدة البيانات 47 من 50 في الخطوة 3، وتُستخدم الاتصالات الخمسون كلها من الخطوة 4. وعندما تنشغل كل الاتصالات تنتظر الطلبات الجديدة اتصالاً حراً، ولهذا يقفز حتى p50، والطلبات التي يطول انتظارها تفشل؛ ويتوافق p99 في الخطوة 3، وهو نحو ضعف p95، مع بدء انتظار أولى الطلبات لاتصال حر. ولا تستطيع أرقام جهة العميل أن تحدد هل المجمّع صغير أم أن الاستعلامات تحجز كل اتصال مدة أطول مما ينبغي، مثل استعلام توفّر المقاعد الجديد على بيانات بحجم الإنتاج؛ لذا يحتاج المطوّرون إلى معالج قاعدة البيانات، وسجل الاستعلامات البطيئة، وانتظارات الأقفال، والوقت الذي تنتظره الطلبات للحصول على اتصال. وتكبير المجمّع ليس هو الإصلاح إن كانت قاعدة البيانات نفسها مشبعة، فالمزيد من الاتصالات يزيدها بطئاً عندئذٍ. يتكرر النمط في الخطوة 5 وتتفق معه مقاييس الخادم، فمن غير المرجّح أن يكون ضوضاء؛ ومع ذلك أعد تشغيل الخطوة 4 للتأكد من أنه يتكرر قبل أن يضبط أحد الكود. أما سؤال معماري النظام فما زال مفتوحاً: خادم تطبيق ثانٍ يضيف قدرة معالجة، وهي ليست الحد، ويضيف اتصالات بقاعدة البيانات لا تنفع إلا إن كان لدى قاعدة البيانات سعة فائضة؛ ويجيب عنه اختبار قابلية التوسع بعد فهم حد قاعدة البيانات.

ما تبلّغ عنه اليوم، كعيب مقابل الأهداف المتفق عليها، إلى مالك المنتج والمطوّرين: «المرشّح للإصدار ⁦3.2.0-rc1⁩، بيئة Staging بحجم الإنتاج، مزيج الذروة، وقت تفكير 7.5 ثانية، خطوات مدة كل منها 10 دقائق. عند 100 طلب في الثانية يبلغ p95 الإجمالي 480 مللي ثانية والأخطاء 0.04% (طُلبت الأرقام لكل رحلة). تتوقف الإنتاجية عند نحو 105 طلبات في الثانية: مع 1,000 مستخدم افتراضي يبلغ p95 نحو 4.1 ثانية وتفشل 1.2% من الطلبات، ومع 1,200 مستخدم يبلغ 7.9 ثانية و4.8%. معالج خادم التطبيق 75%، واتصالات قاعدة البيانات 50 من 50. لم يتحقق هدف الهامش البالغ 150 طلباً في الثانية، فيوم التسجيل معرّض لتكرار ما حدث في الفصل الماضي». أرفق بيانات التشغيل والرسوم البيانية للخادم. وبعد الإصلاح شغّل الاختبار المتدرّج نفسه بالسكربت والبيانات والبيئة نفسها وقارنه بهذا التشغيل (اختبار التأكيد)؛ ثم اختبار الحمل مدة 30 دقيقة عند 100 ثم عند 150 طلباً في الثانية، واختبار الإجهاد فوق 150 طلباً في الثانية، والذروة المفاجئة، ومقارنة قابلية التوسع، واختبار التحمّل. أما تشغيلها الآن فلن يصطدم إلا بالحد نفسه مجدداً.

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