عند العمل على مهام جانب العميل في Discourse (النواة/الإضافات/القوالب)، من المهم مراعاة الأثر على الأداء. يوفر مشروع Google ‘Tachometer’ أداة قياس معياري (Benchmarking) صارمة إحصائيًا يمكننا استخدامها لقياس تأثير التغييرات بشكل قاطع.
في الأساس، تقوم هذه الأداة بأخذ قائمة من عناوين URL وتحميلها بطريقة ‘round-robin’ (تناوب). بالنسبة لكل تحميل للصفحة، تقوم بأخذ بعض قياسات الأداء. بعد مئات أو آلاف التكرارات، تنتج جدول مقارنة.
الجمال في نهج ‘round-robin’ هذا هو أنه يساعد في تقليل تأثير العوامل الخارجية على القياسات.
الخطوة 1: إضافة performance.measure()
ستختلف الطريقة هنا بناءً على ما تختبره. لكن بشكل أساسي: تحتاج إلى إدخال قيمة performance.measure() ليقرأها Tachometer.
إذا كنت تريد قياس الوقت الذي تستغرقه Discourse للتشغيل والعرض، يمكنك استخدام قياس “discourse-init-to-paint” المدمج. لأي شيء آخر، يمكنك إدخال performance.measure خاص بك واستخدامه.
يمكنك التحقق من عمله باستخدام تبويب الأداء في أدوات المطور في متصفحك:
إذا كنت تحاول قياس نشاط يتطلب تفاعل المستخدم (مثل فتح قائمة)، يمكنك تحقيق ذلك بإضافة شيء مثل هذا في مُهيئ (initializer) لنقر الزر بعد ثانية واحدة من تحميل الصفحة:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
الخطوة 2: تحديد عناوين URL للاختبار
أولاً، تأكد من أنك تبني أصول Ember في وضع الإنتاج. يمكن تحقيق ذلك بإطلاق الخادم مع EMBER_ENV=production.
للحصول على عنوانين URL مختلفين، هناك نهجان رئيسيان:
إذا كان تغييرك صغيرًا بما يكفي ليتم وضعه تحت علم ميزة (feature-flag) بسهولة، فيمكنك إضافة منطق للتبديل بناءً على معامل استعلام URL. ثم يمكن أن تكون عناوين URL الخاصة بك هي
http://localhost:3000?flag=before
http://localhost:3000?flag=after
إذا كان التغيير كبيرًا جدًا لذلك، فيمكنك إنشاء git worktree وإطلاق نسخة ثانية من rails منه على منفذ آخر:
git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
تشارك النسختان نفس قاعدة البيانات و Redis، لذا تأكد من أن أحد الفروع لا يحتوي على هجرات (migrations) لا يحتوي عليها الفرع الآخر.
ثم ستكون عناوين URL الخاصة بك هي
http://localhost:3000
http://localhost:3001
إذا اتخذت هذا النهج، تأكد من أن نسختي التطبيق تحتويان على قياسات الأداء التي أدخلتها في الخطوة 1 من هذا الدليل.
الخطوة 3: تكوين Tachometer
هذا هو ملف bench.json الخاص بي، والذي سيأخذ 300 عينة من كل هدف:
{
"timeout": 5,
"sampleSize": 300,
"benchmarks": [
{
"measurement": {
"mode": "performance",
"entryName": "discourse-init-to-paint"
},
"expand": [
{
"url": "http://localhost:3000",
"name": "before"
},
{
"url": "http://localhost:3001",
"name": "after"
}
]
}
]
}
الخطوة 4: تشغيل القياس المعياري
لتقليل الضوضاء، أوقف أي أنشطة غير ذات صلة على جهاز عملك، ثم ابدأ القياس المعياري بأمر مثل:
pnpx tachometer --config ./bench.json
عند الانتهاء، يجب أن ترى مقارنة بين الأداء قبل وبعد التغيير.
ملاحظات وتحذيرات
كما هو الحال مع أي تجارب من هذا النوع، من الجدير النظر في القيود. على سبيل المثال:
-
قد لا تنعكس فروق الأداء على جهاز التطوير الخاص بك مباشرة على المتصفحات/الأجهزة الأخرى.
-
عملية بدء تشغيل Discourse في وضع التطوير ليست هي نفسها تمامًا كما هي في وضع الإنتاج. عند إجراء تغييرات هيكلية (مثل تحديثات الإطار)، قد يكون هذا مهمًا.
-
غالبًا ما يختلف الأداء بناءً على حالة التطبيق (مثل عدد المواضيع التي يتم عرضها)، لذا قد لا تكون نتائجك قابلة للتكرار تمامًا في بيئات أخرى.
هذا المستند مُتحكم فيه إصداريًا - اقترح تغييرات على github.