CPU Throttling في الاختبارات: كيف تحاكي جهازًا أضعف بشكل مفيد

DevTools وبيئات الاختبار تسمح بإبطاء CPU أو تقييد الموارد، وهذا مفيد لرؤية كيف يتصرف UI و Automation تحت جهاز أضعف. لكن 4 x slowdown لا يحول جهازك القوي حرفيًا إلى موديل رخيص؛ architecture و cache و I/O و GPU مختلفة. لذلك اعتبر throttling أداة stress نسبية، لا محاكي hardware كامل.

حدد السؤال الذي تريد إجابته

هل تريد معرفة هل loading spinner يظهر؟ هل selector timeout قصير؟ هل main thread task طويلة؟ استخدم throttling عندما يكون bottleneck CPU-side. إذا المشكلة disk أو RAM أو network، تقييد CPU وحده قد يعطي استنتاجًا مضللًا.

ثبت السيناريو وال ـrate

اختر rate مثل 4 x واستخدمه في كل runs لنفس المقارنة. سجل browser version والجهاز. لا تغير rate في منتصف measurement. نفذ baseline بدون throttling ثم المقيد.

قِس User-centric Latency

سجل time to interactive داخل التطبيق، tab switch latency، click-to-response، و long tasks. لا تكتفِ بمدة script واحدة. على Automation، سجل timeout failures التي لم تظهر في baseline.

راجع Timeouts الثابتة

اختبار CPU أبطأ يكشف sleeps أو timeouts قصيرة مبنية على جهاز المطور. استبدلها waits على condition مع deadline معقول. لا ترفع كل timeouts عالميًا لمجرد نجاح الاختبار؛ أصلح الجزء الذي يحتاج readiness signal.

أضف تقييد شبكة منفصلًا

إذا تريد جهاز/اتصال أضعف، نفذ matrix CPU slow + network normal، CPU normal + network slow، ثم الاثنين. هذا يفصل bottleneck بدل سيناريو واحد شديد لا تعرف سببه.

تحقق على جهاز منخفض فعليًا

قبل وعد أداء أو قرار release، شغل عينة على hardware مرجعي أضعف. استخدم throttling يوميًا لاكتشاف regressions، والجهاز الحقيقي للتحقق النهائي.

اجعل النتيجة نسبية

قل إن الإصدار الجديد زاد P95 20% تحت 4 x throttle مقارنة بالقديم، لا أنه يمثل جهازًا محددًا. القياس النسبي أكثر صدقًا وقابلًا للتكرار.

ابنِ Baseline ثم قارن

لتطبيق «CPU Throttling في الاختبارات: كيف تحاكي جهازًا أضعف بشكل مفيد» بصورة عملية، ثبت جهاز الاختبار وعدد البروفايلات والنسخة والروابط المستخدمة، ثم خذ baseline قبل أي تغيير. سجّل المتوسط وأيضًا أسوأ الحالات الملحوظة مثل p95 عند توفر عدد كافٍ من العينات. أعد السيناريو بعد تنظيف ما يجب تنظيفه فقط، لأن مسح كل cache قد يصنع اختبارًا غير واقعي. إذا ظهر regression، ضيق النطاق بتغيير متغير واحد: نسخة Electron، إضافة، proxy، أو feature flag. بهذه الطريقة يصبح الأداء أو الاستقرار رقمًا يمكن تفسيره لا مجرد إحساس بأن النسخة أسرع أو أبطأ.

معيار القبول قبل الإغلاق

عرّف threshold قبل القياس حتى لا تختار المعيار بعد رؤية النتيجة. سجل نسخة النظام والمتصفح والحمل الخلفي، وكرر الاختبار بما يكفي لإزالة أثر التشغيل الأول. عند ظهور regression، احتفظ بعينة قابلة لإعادة التشغيل قبل محاولة التحسين.

حالة فشل يجب اختبارها

في «CPU Throttling في الاختبارات: كيف تحاكي جهازًا أضعف بشكل مفيد» نفذ جولة قياس بعد تشغيل طويل وليس بعد startup فقط. بعض regressions تظهر مع تراكم tabs أو timers أو extension workers. قارن الذاكرة والاستجابة قبل وبعد السيناريو، وسجل إن كان restart يعيد القيم إلى baseline؛ هذه المعلومة تساعد في فصل leak عن spike مؤقت.