تقدير السعة والأداء المُقاس
السؤال الأول بعد «هل هو آمن» هو «كم مطوّرًا يستوعب». تجيب هذه الوثيقة عنه بأرقام من تشغيل يمكن لأي شخص تكراره مع التحفظات التي تجعل تلك الأرقام صادقة. وحيث لا يدعم القياس ادعاءً ما لا يُطرح ذلك الادعاء.
كل ما يلي مُقاس لا مُقدَّر بنموذج.
القياس
ثلاثون بيئة على كلستر 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 مطوّر ينشئ كل منهم بيئتين تقريبًا في اليوم ويترك متصفحًا يستطلع لوحة التحكم بعيد كل البعد عن أي من هذه الأرقام. وقد افترض قرار النسخة الواحدة «بضع مئات من المطوّرين يجرون كتابات متفرقة». ولا شيء مما قِيس هنا يناقض ذلك.
ما لا تدعمه هذه الأرقام
اقرأ هذا الجزء قبل الاستشهاد بالأرقام أعلاه.
- kind ليس كلسترك. كل عقدة فيه حاوية على جهاز واحد بتخزين محلي ومن دون شبكة حقيقية. الكلستر الحقيقي له أقراص أبطأ وشبكة أبطأ ومستأجرون آخرون. اعتبر هذه الأرقام حدًا أدنى لأداء البرمجية وليست خطة سعة لعتادك.
- 30 بيئة هو ما استوعبه هذا الجهاز وليس حدًا للمنتج. إنه أكبر تشغيل اتسع له الجهاز بارتياح. وبقيت الأرقام ثابتة على امتداده دون أي علامة على نقطة انكسار. أما ما يحدث عند 300 فغير مُقاس ولن نخمّنه.
- لم يتضمن القياس أي بناء. كل بيئة شغّلت صورة مبنية مسبقًا.
- استهلاك الذاكرة خلال اختبار التحمّل غير مُقاس. لا يشغّل kind أي metrics-server لذلك عادت
أرقام ما قبل الاختبار وما بعده بالقيمة
n/a. ولن يظهر تسرّب خلال خمس دقائق بالضرورة على أي حال. والطريقة الصادقة للإجابة عن ذلك اختبار تحمّل أطول على كلستر فيه مقاييس. ولم يُنفَّذ ذلك بعد. - مساحة عمل واحدة بتطبيق واحد وخدمتين لكل بيئة. التطبيق الأكبر يغيّر تكلفة التسوية.
- الوضع المشترك فقط. بيئة الوضع الكامل تشغّل التطبيق كله وتكلّف ما تكلّفه حزمة كاملة واحدة. ولم يكن الوضع الكامل جزءًا من هذا التشغيل.
- لم تكن تعمل بالتوازي أي جلسات طرفية ولا إعادة توجيه إلى SIEM ولا رفع للأدلة.
قواعد تقريبية
إلى أن تقيس كلسترك بنفسك:
- API: نسخة واحدة بـ 500m CPU / 512 MiB مريحة عند هذا الحمل. وهو بنسخة واحدة عن قصد في التصميم. لا توسّعه أفقيًا. ولن تحتاج إلى ذلك.
- المشغّل: نسخة واحدة. عمليات التسوية قصيرة والعمل يجري لكل بيئة على حدة.
- حجم البيانات: سجل التدقيق لا يفعل سوى النمو. كتب اختبار التحمّل 12640 مدخلًا في خمس
دقائق عند نحو 42 كتابة في الثانية بلا توقف وهو معدل أعلى بكثير من أي تثبيت حقيقي. التثبيت
الحقيقي لـ 200 مطوّر يكتب بضعة آلاف من المدخلات في اليوم. اختر حجم وحدة التخزين بما يكفي لسنوات
وراقب
nezal_data_volume_free_bytes. وأرشف النطاقات القديمة إلى تخزين الكائنات. - لكل بيئة في الوضع المشترك: ما تطلبه الخدمات التي تستبدلها من موارد. والأساس المشترك تُدفع كلفته مرة واحدة لكل تطبيق وليس مرة لكل مطوّر.
- لكل بيئة في الوضع الكامل: حزمة كاملة واحدة. اختر حجم الكلستر بما يكفي لحزمة واحدة لكل مطوّر لديه بيئة واستخدم حدود البيئات والمدة (TTL) في السياسة (Policy) لتقييد ذلك.
تكرار القياس
شغّل hack/load.sh لتكرار القياس على kind. ويغيّر الأمر ENVS=60 SOAK=30m hack/load.sh الحجم
والمدة. وعلى كلسترك تعمل أي أداة تحميل: أنشئ بيئات عبر API أو CLI بالتوازي وأبقِها طوال فترة
اختبار التحمّل. واقرأ زمن استجابة API من nezal_api_request_duration_seconds على /metrics
والوقت حتى Ready من حالات (conditions) كل Environment.
يفشل السكربت إذا لم تتحقق سلامة سلسلة التدقيق في النهاية. وليس ذلك زينة: هذا القياس هو ما كشف خللًا في التقييس (canonicalisation) في سلسلة التدقيق. فقد أبلغت السلسلة عن تلاعب في سجل لم يمسّه أحد.