تقدير السعة والأداء المُقاس

السؤال الأول بعد «هل هو آمن» هو «كم مطوّرًا يستوعب». تجيب هذه الوثيقة عنه بأرقام من تشغيل يمكن لأي شخص تكراره مع التحفظات التي تجعل تلك الأرقام صادقة. وحيث لا يدعم القياس ادعاءً ما لا يُطرح ذلك الادعاء.

كل ما يلي مُقاس لا مُقدَّر بنموذج.

القياس

ثلاثون بيئة على كلستر kind ثُبّت نزال عليه عبر مخطط Helm تمامًا كما يثبّته العميل. وأُبقيت البيئات تحت الحمل لخمس دقائق. والسكربت هو hack/load.sh.

ينشئ القياس N بيئة عبر API وينتظر أن تبلّغ كل منها عن حالة Ready. ثم يضغط مسار القراءة بعملاء متزامنين ويجري اختبار تحمّل مستمر (soak) مع عدة كاتبين يضيفون مدخلات إلى سلسلة التدقيق. وأخيرًا يتحقق من السلسلة. تُحفظ النتائج في .load-results/.

النتائج

قِيست بتاريخ 2026-09-12 على Apple M4 Pro بـ 14 نواة و24 GiB من الذاكرة ونظام macOS 26.5.2. وكان Docker Desktop بـ 14 وحدة CPU. والكلستر kind بعقدة واحدة مع نسخة واحدة من API ونسخة واحدة من المشغّل.

إنشاء البيئات

البيئات المطلوبة 30
وصلت إلى Ready 30 من 30
الوقت حتى Ready p50 6.3 s يرتفع إلى p95 7.3 s والحد الأقصى 7.3 s
الزمن الكلي للبيئات الثلاثين 34 s مع ستة إنشاءات متزامنة

قِيس من لحظة قبول API لطلب الإنشاء إلى أن يبلّغ Environment عن حالة Ready أي التسوية (reconcile) وجدولة الـ Pod وتحديث التوجيه. وهذا ما ينتظره المطوّر فعلًا.

كانت هذه بيئات في الوضع المشترك تنشر صورة مبنية مسبقًا. البناء من المصدر يضيف زمن البناء. وهو يعتمد على مستودعك وسجل الصور لديك وغير مشمول هنا.

حمل القراءة على API

الحمل 20 عميلًا متزامنًا لمدة 60 s على GET /environments
الإنتاجية 290 طلبًا في الثانية
الأخطاء 0 استجابة غير 2xx من أصل 17411
زمن الاستجابة p50 13 ms يرتفع إلى p95 24 ms وp99 78 ms والحد الأقصى 128 ms

هذه هي نقطة النهاية التي تستطلعها لوحة التحكم مع 30 بيئة في مساحة العمل.

اختبار التحمّل مع إضافات متواصلة إلى سجل التدقيق

المدة 5 دقائق مع 4 كاتبين متزامنين
الكتابات 12640 مع 0 أخطاء
زمن الاستجابة p50 8 ms يرتفع إلى p95 15 ms وp99 17 ms والحد الأقصى 28 ms
سلسلة التدقيق بعد الانتهاء تحققت سلامتها

كل كتابة تُضاف إلى سلسلة التجزئة وهذا لا يمكن تنفيذه بالتوازي داخل قاعدة البيانات. فكل مدخل تُحسب تجزئته فوق تجزئة المدخل السابق. وأربعة كاتبين متزامنين هو النمط الذي كان سيكشف ذلك عنقَ زجاجة. وعند هذا المعدل لم يكن كذلك: زمن الكتابة أقل من زمن القراءة لأن القراءة تُحوّل 30 بيئة إلى JSON بينما الكتابة تضيف صفًا واحدًا.

ما تدعمه هذه الأرقام

اختُبر حتى 30 بيئة متزامنة على حاسوب محمول بـ 14 نواة مع API يجيب عن 290 قراءة في الثانية عند p99 قدره 78 ms ويحافظ على 42 كتابة مدقَّقة في الثانية مع بقاء السلسلة سليمة.

لتصوّر تقريبي للحجم: فريق من 200 مطوّر ينشئ كل منهم بيئتين تقريبًا في اليوم ويترك متصفحًا يستطلع لوحة التحكم بعيد كل البعد عن أي من هذه الأرقام. وقد افترض قرار النسخة الواحدة «بضع مئات من المطوّرين يجرون كتابات متفرقة». ولا شيء مما قِيس هنا يناقض ذلك.

ما لا تدعمه هذه الأرقام

اقرأ هذا الجزء قبل الاستشهاد بالأرقام أعلاه.

قواعد تقريبية

إلى أن تقيس كلسترك بنفسك:

تكرار القياس

شغّل hack/load.sh لتكرار القياس على kind. ويغيّر الأمر ENVS=60 SOAK=30m hack/load.sh الحجم والمدة. وعلى كلسترك تعمل أي أداة تحميل: أنشئ بيئات عبر API أو CLI بالتوازي وأبقِها طوال فترة اختبار التحمّل. واقرأ زمن استجابة API من nezal_api_request_duration_seconds على /metrics والوقت حتى Ready من حالات (conditions) كل Environment.

يفشل السكربت إذا لم تتحقق سلامة سلسلة التدقيق في النهاية. وليس ذلك زينة: هذا القياس هو ما كشف خللًا في التقييس (canonicalisation) في سلسلة التدقيق. فقد أبلغت السلسلة عن تلاعب في سجل لم يمسّه أحد.