تحليل نتائج اختبار الأداء
تحليل نتائج الأداء هو الخطوة بين انتهاء تشغيل اختبار حمل أو إجهاد أو ذروة مفاجئة أو تحمّل أو سعة، واتخاذ القرار. فأداة الحمل تُظهر النظام من الخارج: مئينات (Percentiles) زمن الاستجابة والإنتاجية (Throughput) ومعدل الأخطاء عبر الزمن. والمراقبة (Monitoring) تُظهره من الداخل: استخدام المعالج والذاكرة وقاعدة البيانات والشبكة على الخط الزمني نفسه. ويجمع التحليل بين الاثنين ليجيب عن ثلاثة أسئلة: هل تحققت الأهداف؟ وأيّ مورد قيّد النظام أولاً؟ وما الذي ينبغي تغييره قبل التشغيل التالي؟
مثلاً، حققت واجهة إتمام الشراء أهدافها عند 40 طلباً في الثانية وأخفقت فيها عند 60. جدول الملخص لا يقول سوى «بطيء». أما الخط الزمني فيُظهر أن هدف الأخطاء لم يتحقق بينما بقي p95 ضمن هدفه، وأن مجمّع اتصالات قاعدة البيانات (Connection Pool) عند 10 من 10 بينما معالج قاعدة البيانات عند 48%، ولا استعلامات بطيئة في السجل. هذه ليست قاعدة بيانات بطيئة، بل مجمّع اتصالات أصغر من اللازم أو اتصالات محجوزة أطول من اللازم، والإصلاح مختلف.
لماذا يهم
يُنتج التشغيل الواحد آلاف الأرقام، ولا بد أن يخرج منها قرار: الإطلاق أو الانتظار، شراء قاعدة بيانات أكبر أو إضافة خوادم تطبيق، إصلاح استعلام أو تغيير حجم مجمّع اتصالات. اقرأ الرقم الخطأ فيقضي الفريق أسابيع في توسيع طبقة لم تكن الحدّ أصلاً، كما أظهرت الهضبة في الدرس السابق. واقرأ الرقم الصحيح فقد يضاعف تغييرٌ من سطر واحد في الإعدادات السعةَ.
أما للمختبِر، فالتحليل هو ما يحوّل اختبار الأداء من رسم بياني إلى ملاحظة (Finding). فعبارة «النظام بطيء عند 60 طلباً في الثانية» لا يمكن إسنادها إلى أحد. أما «من 60 طلباً في الثانية يتشبّع مجمّع اتصالات قاعدة البيانات بينما يبقى معالجها تحت 50%؛ فتنتظر الطلبات اتصالاً ويفشل 0.6% منها» فيمكن إسنادها وإصلاحها وإعادة اختبارها.
تحقّق من التشغيل، ثم اقرأ المنحنيات معاً
تحقّق أولاً من أن التشغيل يستحق التفسير. هل بلغت الأداة الحمل المخطط له بينما ظل معالجها وشبكتها بعيدَين عن حدودهما؟ هل استُثني الصعود التدريجي (Ramp-up) والهبوط التدريجي (Ramp-down) من الأرقام؟ هل احتُسبت حالات انتهاء المهلة وأخطاء الاتصال أخطاءً كما اتُّفق؟ هل طابق الإصدار والبيئة وحجم البيانات الخطة؟ والتشغيل الثاني الذي لا يعيد إنتاج الأول ضوضاء: أصلح البيئة قبل الحكم على الشيفرة.
ثم اقرأ المنحنيات عبر الزمن لا جدول الملخص. فأدوات الحمل مثل k6 وJMeter تستطيع كتابة نتائج كل طلب مع طابعه الزمني، لا ملخص نهاية التشغيل فقط؛ استخدم هذا المخرج. ضع الإنتاجية وp50 وp95 وp99 ومعدل الأخطاء والموارد الرئيسية على محور زمني واحد وابحث عن أربع علامات.
- يرتفع زمن الاستجابة بينما تستوي الإنتاجية: نقطة انحناء المنحنى (Knee). مورد ما تشبّع (Saturated) والطلبات تنتظره في طابور. ونقطة الانحناء تحدد أقصى ما يمكن أن يمرّ من هذا العبء؛ أما السعة، كما في الدرس السابق، فهي آخر خطوة عندها أو قبلها تتحقق فيها كل الأهداف.
- ترتفع الأخطاء قبل زمن الاستجابة: حدّ صارم (Hard Limit) لا بطء. شيء ذو حجم ثابت (مجمّع اتصالات، مجمّع خيوط، حدّ اتصالات أو حدّ معدل، طابور) يرفض الفائض أو يُنهي مهلته بـ HTTP 503 أو 429 أو انتهاء المهلة بينما تبقى المعالجات بعيدة عن سقفها.
- p99 أعلى بكثير من p95: معظم الطلبات سليمة وبضعة منها تصطدم بشيء بطيء، مثل توقفات جمع القمامة (Garbage Collection)، أو تنافس الأقفال (Lock Contention)، أو مسار عدم الإصابة في الذاكرة المؤقتة (Cache Miss)، أو استدعاء بطيء لخدمة تابعة (Downstream).
- تدهور بطيء عند حمل ثابت: تسرّب أو استنفاد للذاكرة أو الاتصالات أو مقابض الملفات أو القرص، كما في درس اختبار التحمّل.
اعثر على عنق الزجاجة: المعالج والذاكرة وقاعدة البيانات والشبكة
عنق الزجاجة (Bottleneck) هو المورد الذي يتشبّع أولاً لحظة انحناء المنحنى؛ وكل ما بعده نتيجة له. فعندما يمتلئ مجمّع اتصالات قاعدة البيانات تنتظر خيوط التطبيق، وتتكدّس الطلبات عند موزّع الحمل، ويرى العميل انتهاء المهلة. شخّص بترتيب ثابت، الفحص الأرخص أولاً، وتوقف عند أول مورد متشبّع عند نقطة الانحناء. ثم تحقّق من أنه سبب لا نتيجة: فالمعالج المشغول بجمع القمامة يشير إلى الذاكرة، والمشغول بإعادة المحاولات يشير إلى الإخفاق الذي يسببها.
- الحدود الصارمة: أخطاء بينما المعالجات بعيدة عن سقفها. ابحث عن مجمّع أو عدد خيوط أو حدّ اتصالات أو طابور أو حدّ معدل مستخدم بنسبة 100%. والإصلاح إعداد أو تغيير في التصميم، مثل تحرير الاتصالات مبكراً، لا عتاد إضافي.
- المعالج: معالج تطبيق أو قاعدة بيانات قريب من سقفه باستمرار عند نقطة الانحناء (الطبقات المتشبّعة في الدرس السابق عملت عند نحو 90% أو أكثر). معالج التطبيق يستجيب للتحليل الأدائي (Profiling) والتوسع الأفقي؛ أما معالج قاعدة البيانات فيعني عادةً استعلامات مكلفة أو كثيرة جداً، وإضافة خوادم تطبيق لا تساعد وقد تزيده سوءاً.
- الذاكرة: ذاكرة تطبيق (Heap) تنمو ولا تتقلّص، أو جمع قمامة يستهلك حصة متزايدة من الوقت، أو تبديل إلى القرص (Swapping)، أو إعادة تشغيل بعد نفاد الذاكرة. تظهر توقفات GC كقفزات في p99، ويبطّئ التبديل كل شيء معاً، وتظهر إعادة التشغيل كدفعات من أخطاء الاتصال مع هبوط الذاكرة إلى الصفر.
- انتظار قاعدة البيانات والتبعيات: خيوط التطبيق خاملة والطلبات بطيئة، أو إدخالات في سجل الاستعلامات البطيئة، أو انتظار أقفال، أو انتظار إدخال/إخراج (I/O)، أو واجهة طرف ثالث تجيب في ثوانٍ. وتتبّع (Trace) طلب بطيء واحد يُظهر أيّ استدعاء يحتجز الوقت.
- الشبكة والحمولة: بايتات في الثانية قريبة من سعة الوصلة، أو استجابات كبيرة أو غير مضغوطة، أو جولات ذهاب وإياب كثيرة لكل صفحة، أو إعادة إرسال. فعند 100 طلب في الثانية تحتاج استجابات بحجم 2 ميغابايت إلى 1.6 جيجابت في الثانية، أي أكثر مما تحمله وصلة سعتها 1 جيجابت في الثانية مهما كان الخادم سريعاً؛ افحص الحجم قبل لوم الخادم.
- لا شيء متشبّع: اشتبه في قفل أو طابور واحد يُسلسل العمل، أو حدّ لم ترسمه بعد، أو هدف غير واقعي. أضف المراقبة للطبقة الناقصة وأعد التشغيل بدلاً من التخمين.
الإجابة: لا
النتيجة: حدّ الأداة: النتائج تصف المولّدأصلح المولّد أو وسّعه ثم أعد التشغيل.الإجابة: نعم
سؤال 2: هل ترتفع الأخطاء (503 و429 وانتهاء المهلة) بينما تبقى المعالجات كلها بعيدة عن سقفها؟الإجابة: نعم
النتيجة: حدّ صارممجمّع اتصالات أو مجمّع خيوط أو حدّ اتصالات أو طابور أو حدّ معدل مستخدم بنسبة 100%. إعداد أو تغيير في التصميم، لا عتاد.الإجابة: لا
سؤال 3: هل يوجد معالج قريب من سقفه باستمرار عند نقطة الانحناء؟الإجابة: نعم، طبقة التطبيق
النتيجة: معالج التطبيقاستبعد وقت جمع القمامة أولاً، ثم حلّل الشيفرة الساخنة أدائياً أو وسّع أفقياً.الإجابة: نعم، خادم قاعدة البيانات
النتيجة: معالج قاعدة البياناتاستعلامات مكلفة أو كثيرة جداً؛ إضافة خوادم تطبيق لا تساعد وقد تزيده سوءاً.الإجابة: لا
سؤال 4: هل تنمو الذاكرة، أم أن جامع القمامة مشغول، أم أن الخادم يبدّل إلى القرص؟الإجابة: نعم
النتيجة: الذاكرةتسرّب أو ذاكرة تطبيق أصغر من اللازم. تظهر توقفات GC كـ p99 أعلى بكثير من p95؛ والتبديل يبطّئ كل شيء معاً.الإجابة: لا
سؤال 5: هل يُقضى الوقت في انتظار قاعدة البيانات أو خدمة تابعة؟الإجابة: نعم
النتيجة: انتظار قاعدة البيانات أو التبعياتاستعلامات بطيئة أو تنافس أقفال أو انتظار إدخال/إخراج أو واجهة طرف ثالث بطيئة؛ التتبّع يُظهر أيّها.الإجابة: لا
سؤال 6: هل الوصلة الشبكية أو الحمولة هي الحدّ؟الإجابة: نعم
النتيجة: الشبكة والحمولةعرض نطاق قريب من سقفه، أو استجابات كبيرة أو غير مضغوطة، أو جولات كثيرة أو إعادة إرسال.الإجابة: لا
النتيجة: لا مورد متشبّعاشتبه في قفل أو طابور واحد، أو حدّ لم ترسمه، أو هدف غير واقعي؛ أضف المراقبة وأعد التشغيل.
اربط التشغيل بالمراقبة
أداة الحمل مراقبة من نوع الصندوق الأسود (Black-box Monitoring): ترى الأعراض من الخارج. ومراقبة الخوادم من نوع الصندوق الأبيض (White-box): ترى الأسباب من الداخل. والإشارات الذهبية الأربع (Golden Signals) في كتاب Google SRE، وهي الكمون (Latency) وحركة المرور (Traffic) والأخطاء (Errors) والتشبّع (Saturation)، تسمّي ما يجب محاذاته: الأداة تعطي الثلاث الأولى، والخوادم تعطي التشبّع، ولا ينجح الربط إلا حين يتشارك الطرفان خطاً زمنياً واحداً.
- خط زمني واحد: زامن الساعات والمناطق الزمنية، وسجّل وقت البداية والنهاية وكل خطوة حمل بالساعة، وضع علامات الخطوات على لوحات المراقبة. فنتائج JMeter بصيغة CSV مثلاً تعطي وقت كل عينة بالمللي ثانية منذ 1 يناير 1970 (UTC)؛ حوّله إلى المنطقة الزمنية للوحة المراقبة. وقارن نوافذ الحالة المستقرة (Steady State) فقط، لا نافذة تتضمن الصعود التدريجي.
- امشِ عبر الطبقات بترتيب الطلب: موزّع الحمل (الاتصالات النشطة، أخطاء 5xx)، ثم التطبيق (الطلبات والكمون لكل نقطة نهاية، مجمّعات الخيوط والاتصالات، GC، الذاكرة)، ثم قاعدة البيانات (الاتصالات، الاستعلامات البطيئة، انتظار الأقفال، المعالج، الإدخال/الإخراج)، ثم البنية التحتية (المعالج، الذاكرة، القرص، بايتات الشبكة)، ثم السجلات والتتبّعات للطلبات البطيئة المفردة.
- المقياس الذي يتحرك لحظة انحناء المنحنى فرضية لا دليل. غيّر شيئاً واحداً (كبّر المجمّع، أضف الفهرس، وسّع أفقياً)، وأعد التشغيل، وتحقّق هل تحرّكت نقطة الانحناء. إن لم تتحرك فعنق الزجاجة في مكان آخر؛ وإن تحرّكت فقد صار التالي مرئياً.
مثال تطبيقي: تشغيل إتمام شراء أخفق في هدفه
أجرى متجر إلكتروني اختبار حمل متدرّجاً على POST /api/checkout في بيئة Staging، عشر دقائق لكل خطوة، بهدف p95 أقل من 800 مللي ثانية وأخطاء أقل من 0.5% عند 60 طلباً في الثانية. وبقي مولّد الحمل تحت 30% من معالجه. يجمع الجدول نتائج الأداة مع لوحات المراقبة للحالة المستقرة في كل خطوة؛ والعمود «Offered» هو معدل الوصول الذي طبّقته الأداة، و«Completed» هو الإنتاجية.
- تخفق الخطوة 3 في هدف الأخطاء (0.6%) رغم نجاح p95 بالكاد، ويُظهر p99 عند 2,100 مللي ثانية ذيلاً بطيئاً. هنا ينحني المنحنى: تعرض الخطوة 4 زيادة 20 طلباً في الثانية لكنها لا تُكمل سوى 3 طلبات إضافية في الثانية.
- لم يتشبّع أيٌّ من المعالجَين (التطبيق 64% وقاعدة البيانات 48%)، لكن مجمّع اتصالات قاعدة البيانات عند 10 من 10 منذ الخطوة 3، والأخطاء هي 503 وانتهاء مهلة: حدّ صارم. وسجل الاستعلامات البطيئة لا يحوي شيئاً فوق 100 مللي ثانية، فقاعدة البيانات ليست بطيئة؛ الاتصالات هي الشحيحة. ويُظهر تتبّع عملية إتمام شراء واحدة أن المعاملة تبقى مفتوحة أثناء استدعاء مزوّد الدفع (نحو 120 مللي ثانية من 180 تستغرقها العملية عند الحمل المنخفض)، فيحتجز كل طلب اتصالاً معظم عمره. ويؤكد قانون ليتل (Little’s Law) ذلك: 10 اتصالات يُحتجز كل منها نحو 0.15 ثانية تخدم نحو 65 طلباً في الثانية على الأكثر (10 ÷ 0.15)، وهو قريب من الطلبات الـ 61 المكتملة في الخطوة 4.
- الملاحظة: من 60 طلباً في الثانية يتشبّع مجمّع اتصالات قاعدة البيانات (10) في خدمة إتمام الشراء بينما يبقى معالج قاعدة البيانات تحت 50%؛ فتنتظر الطلبات اتصالاً ويفشل 0.6% منها بـ 503 أو انتهاء المهلة. السبب المشتبه به: الاتصال محجوز طوال استدعاء مزوّد الدفع. التجربة التالية: حرّر الاتصال قبل الاستدعاء الخارجي، أو كبّر المجمّع إلى 20 إن سمح حدّ اتصالات قاعدة البيانات، ثم أعد تشغيل الخطوتين 3 و4.
POST /api/checkout · staging · build 4.12.0 · 10 min per step · steady state only
Target at 60 req/s: p95 < 800 ms, errors < 0.5 %
Step Offered Completed p50 p95 p99 Errors App CPU DB CPU DB pool Heap
req/s req/s ms ms ms
1 20 20 180 310 420 0.0 % 28 % 22 % 3/10 1.1 GB
2 40 40 190 350 520 0.0 % 51 % 41 % 6/10 1.2 GB
3 60 58 240 790 2,100 0.6 % 64 % 48 % 10/10 1.2 GB
4 80 61 610 3,400 5,000 7.8 % 66 % 49 % 10/10 1.2 GB
5,000 ms = client timeout. Errors: HTTP 503 and timeouts. Slow-query log: none > 100 ms.اكتب ملاحظة يمكن التصرف بناءً عليها
يجيب تقرير الأداء عن ثلاثة أسئلة لثلاث فئات من القرّاء: هل تحققت الأهداف (مالك المنتج ومدير الإصدار)، وما الذي يقيّد النظام ولماذا (المطورون والعمليات)، وما الذي ينبغي تغييره قبل التشغيل التالي (الجميع). ويعامل منهج ISTQB لاختبار الأداء تحليل النتائج والإبلاغ عنها مهمةً مستقلة تلي التنفيذ. اذكر الحكم أولاً ثم الدليل، واحتفظ بالنتائج الخام ليُقارن التشغيل التالي بالمثل.
- حكم لكل هدف: الهدف والقيمة المقاسة ونجاح أو فشل وعند أيّ حمل: «p95 يساوي 790 مللي ثانية (الهدف 800) ناجح؛ الأخطاء 0.6% (الهدف 0.5%) فشل، عند 60 طلباً في الثانية».
- سياق يجعل الأرقام قابلة للمقارنة: الإصدار، والبيئة وكيف تختلف عن الإنتاج، وحجم البيانات، ونموذج عبء العمل، ومخطط الحمل، والتواريخ، والأداة وإصدارها، وما احتُسب خطأً.
- ملاحظات مكتوبة كتقارير العيوب: المُلاحَظ مقابل المتوقع بأرقام دقيقة، والمورد المتشبّع ودليله المترابط، وإمكانية إعادة الإنتاج عبر تشغيلَين، والأثر عند الحمل المتوقع، والخطورة. ملاحظة واحدة لكل عنق زجاجة.
- توصيات على شكل تجارب: ما الذي يُغيَّر، وأيّ مقياس ينبغي أن يتحرك، وإعادة التشغيل التي تؤكد ذلك. وأضف حدود الاختبار كي لا يقرأ أحد رقم Staging وعداً للإنتاج.
- صيغتان من تحليل واحد: ملخص قصير بكلمات بسيطة لما سيعيشه المستخدمون، والجداول والرسوم المشروحة للمهندسين.
أخطاء شائعة
- قراءة جدول الملخص فقط. فالمتوسطات والمجاميع تخفي نقطة الانحناء والذيل البطيء ولحظة بدء الأخطاء.
- لوم أول مورد مشغول. فمعالج عند 100% قد يكون نتيجة لإعادة المحاولات أو لجمع القمامة؛ وعنق الزجاجة هو ما تشبّع أولاً عند نقطة الانحناء.
- مقارنة خط زمني من العميل بلوحة مراقبة في منطقة زمنية أخرى، أو نافذة حالة مستقرة بنافذة تتضمن الصعود التدريجي.
- معاملة الترابط دليلاً والتوصية بإصلاح دون إعادة التشغيل التي تؤكده.
- الإبلاغ بأن «النظام بطيء» دون مستوى الحمل والهدف والمورد المتشبّع والأرقام.
- تغيير عدة أشياء بين التشغيلَين، فلا يعرف أحد أيّ تغيير حرّك نقطة الانحناء.
من منظور ضمان الجودة
في الفريق الحقيقي نادراً ما يملك المختبِر لوحات المراقبة، لذا يبدأ التحليل قبل التشغيل: اطلب من فريق العمليات صلاحية الوصول إلى المراقبة، واتفق على المنطقة الزمنية، واكتب خطة التشغيل بأوقات الخطوات، واطلب من مطوّر أن يكون متاحاً أثناء التشغيل. وبعده أجرِ المرور الأول عبر الطبقات مع مطوّر أو مهندس عمليات؛ فالأمر أسرع بوجود من يعرف حجم المجمّع. ولا تحمّل إلا الأنظمة التي تملكها أو لديك إذن كتابي باختبارها.
احتفظ لكل تشغيل بالخطة والنتائج الخام والسلاسل المصدَّرة أو لقطات الشاشة لنوافذ الحالة المستقرة والملاحظات والقرار المتخذ. فالتشغيل التالي يُقارن بهذا، والجدول نفسه بعد الإصلاح هو الدليل على أن الإصلاح نجح. وحين تُنازَع ملاحظة، يحسمها الخط الزمني المترابط.
تمرين عملي
شخّص تشغيلاً لواجهة البحث واكتب الملاحظة
أنتج اختبار حمل متدرّج على GET /api/search في بيئة Staging الجدول أدناه. الهدف p95 أقل من 300 مللي ثانية وأخطاء أقل من 1% عند 150 طلباً في الثانية؛ وبقي مولّد الحمل تحت 25% من معالجه.
حدّد الخطوة التي ينحني فيها المنحنى، وسمِّ عنق الزجاجة مع دليلك، واذكر ما ستفحصه في المراقبة بعد ذلك، واكتب الملاحظة كما ستبلغ عنها.
GET /api/search · staging · build 2.8.1 · 10 min per step · steady state only
Target at 150 req/s: p95 < 300 ms, errors < 1 %
Step Offered Completed p50 p95 p99 Errors App CPU DB CPU DB pool Heap
req/s req/s ms ms ms
1 50 50 80 140 210 0.0 % 35 % 30 % 3/50 0.9 GB
2 100 100 95 190 290 0.0 % 62 % 57 % 7/50 1.0 GB
3 150 149 160 420 900 0.1 % 71 % 96 % 23/50 1.0 GB
4 200 152 480 1,900 3,600 2.4 % 70 % 98 % 49/50 1.0 GB
Errors: HTTP 503 and timeouts. Slow-query log at step 3: 52,000 entries over 100 ms,
all the same search query on the products table (full scan of 300,000 rows).- اعثر على الخطوة التي يرتفع فيها زمن الاستجابة بينما تتوقف الإنتاجية المكتملة عن الارتفاع.
- افحص أيّ الموارد قريب من سقفه عند تلك الخطوة، وأيّها ليس كذلك.
- قرّر هل العلامة حدّ صارم أم معالج أم ذاكرة أم قاعدة بيانات أم شبكة.
- اكتب الملاحظة بالأرقام والدليل والسبب المشتبه به والتجربة التالية.
إظهار الإجابة النموذجية
نقطة الانحناء عند الخطوة 3: يرتفع p95 من 190 إلى 420 مللي ثانية وp99 إلى 900، بينما تعرض الخطوة 4 زيادة 50 طلباً في الثانية ولا تُكمل سوى 3 إضافية. لم يتحقق هدف p95 عند 150 طلباً في الثانية؛ أما الأخطاء (0.1%) فما تزال ضمن الهدف هناك، فليس هذا حداً صارماً.
معالج قاعدة البيانات متشبّع (96% ثم 98%) عند نقطة الانحناء تماماً، بينما معالج التطبيق (71%) ليس كذلك والذاكرة ثابتة. ولا يمتلئ المجمّع إلا في الخطوة 4 (49 من 50) لأن الاستعلامات البطيئة تحتجز الاتصالات أطول: نتيجة لا سبب. ويدلّ سجل الاستعلامات البطيئة على السبب: في الخطوة 3 تجاوزت 52,000 عملية بحث من نحو 89,000 (149 طلباً في الثانية لعشر دقائق) حدّ 100 مللي ثانية، وكلها الاستعلام نفسه الذي يمسح جدول المنتجات كاملاً بصفوفه البالغة 300,000. التالي في المراقبة: انتظار الإدخال/الإخراج في قاعدة البيانات ونسبة إصابة الذاكرة المؤقتة للنافذة نفسها، وتتبّع عملية بحث بطيئة واحدة.
الملاحظة: من 150 طلباً في الثانية يُخفق البحث في هدف p95 (420 مللي ثانية، والهدف 300) لأن معالج قاعدة البيانات يتشبّع عند 96%؛ ويُظهر سجل الاستعلامات البطيئة أن استعلام البحث يمسح جدول المنتجات كاملاً (300,000 صف). وتبقى الأخطاء ضمن الهدف عند 150 طلباً في الثانية ولا تتجاوزه إلا عند 200 (2.4%). السبب المشتبه به: فهرس مفقود لمرشّح البحث. التجربة التالية: أضف الفهرس في Staging، وأعد تشغيل الخطوات من 2 إلى 4، وتحقّق من انخفاض معالج قاعدة البيانات عند 150 طلباً في الثانية وانتقال نقطة الانحناء إلى ما بعد 200. وإضافة نسخ من التطبيق لن تساعد: فمعالج التطبيق عند 71%.
أسئلة شائعة
ما الذي أقرأه أولاً: نتائج أداة الحمل أم لوحات مراقبة الخوادم؟
نتائج الأداة أولاً، لتعرف هل تحققت الأهداف ومتى توقفت عن التحقق، وأين ينحني المنحنى. ثم لوحات المراقبة لتلك النافذة بالضبط، لتعرف أيّ مورد تشبّع. فالأداة تُظهر الأعراض، والمراقبة تُظهر الأسباب.
هل يمكن أن يوجد أكثر من عنق زجاجة؟
نعم، لكن في الغالب لا يقيّد إنتاجيةَ عبء عمل معيّن إلا واحدٌ منها في كل مرة. فحين تعالج الأول ترتفع الإنتاجية حتى يتشبّع المورد التالي، كما أظهرت هضبة درس السعة حين انتقل الحدّ من طبقة التطبيق إلى قاعدة البيانات. أبلغ عن النشط عند نقطة الانحناء وتوقّع التالي بعد الإصلاح.
هل أحتاج إلى التتبّع الموزّع لتحليل النتائج؟
لا. فالمقاييس على خط زمني واحد مع سجل الاستعلامات البطيئة تكفي غالباً للعثور على عنق الزجاجة. ويساعد التتبّع حين تقول المقاييس «انتظار» دون أن تقول على ماذا: فهو يُظهر أين ذهب وقت طلب بطيء واحد عبر الخدمات.
وماذا لو حقق التشغيل كل الأهداف؟
أبلغ عنه أيضاً: الهامش المقاس (كم يقع الحمل المستهدف تحت السعة)، والمورد الأقرب إلى سقفه، والاتجاه مقارنةً بالتشغيل السابق. فالنجاح بهامش يتقلّص تحذير.
المراجع
- Certified Tester Performance Testing (CT-PT)منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
- Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
- Grafana k6 documentationالتوثيق الرسمي لأداة Grafana k6، وهي أداة مفتوحة المصدر وقابلة للتوسعة لاختبار الحمل والأداء.
- Apache JMeter User's Manualكيف تُبنى اختبارات الحمل وتُعامَل بالمعاملات وتُشغَّل في JMeter، وكيف تُقرأ مستمعاته وتقاريره.
تدرّب بأدوات متقن
شغّل قياس أداء صغيراً وآمناً على نقطة نهاية عامة (بعدد طلبات وتزامن محدودَين) واحصل على الإنتاجية ومئينيات زمن الاستجابة.
قِس زمن استجابة نقطة نهاية عبر عدة عيّنات: الحد الأدنى والأقصى والمتوسط والوسيط وp95.
حلّل حجم الاستجابة: البايتات الخام مقابل المضغوطة، وحجم الترويسات، ووزن بنية JSON، وأكبر الحقول.
حوّل الطوابع الزمنية (ثوانٍ، ميلي ثانية، ميكرو ثانية) إلى تواريخ مقروءة وبالعكس، بأي منطقة زمنية.
قارن أزمنة الاستجابة والأحجام بين نقطتي نهاية (مثل v1 مقابل v2، أو staging مقابل الإنتاج) جنباً إلى جنب.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.