قدّر أقصى معدل معاملات (TPS) تستطيع بنيتك تحمّله، وأي مكوّن يصبح عنق الزجاجة، بناءً على مواصفات الخادم وبيئة التشغيل وإعداد قاعدة البيانات.
الأساس هو قانون ليتل: عدد الطلبات المتزامنة يساوي معدل المعاملات في الثانية مضروبًا في زمن الاستجابة. وبقلب المعادلة نحصل على سقف TPS لأي مورد بقسمة سعته المتزامنة على زمن الاستجابة.
يُجرى هذا الحساب لكل مورد على حدة: المعالج، والمقابس (sockets)، وبِركة الخيوط، وبِركة اتصالات قاعدة البيانات. لكل واحد منها سقفه الخاص المستقل عن الآخرين.
ثم يصبح أدنى هذه السقوف هو سقف النظام بأكمله، ويُعرَض المورد صاحبه بوصفه عنق الزجاجة. ومهما ضاعفت باقي الموارد فلن يرتفع الأداء ما لم تعالج هذه النقطة تحديدًا.
مثال: سقف المعالج يساوي عدد الأنوية مقسومًا على زمن المعالجة لكل طلب مضروبًا في عدد الخوادم. أربعة أنوية وزمن معالجة 2 ميلي ثانية يعني 2000 طلب في الثانية للخادم الواحد.
خيط لكل طلب (كما في Spring MVC التقليدي) يحتجز الخيط طوال انتظار الإدخال والإخراج الخارجي. لذلك تنفد بِركة الخيوط أولًا ويتوقّف نمو TPS بينما المعالج ما زال شبه خامل.
السقف هنا يساوي حجم بِركة الخيوط مقسومًا على زمن المعالجة الكلي مضروبًا في عدد الخوادم. والمهم أن الزمن الكلي يشمل انتظار قاعدة البيانات وواجهات البرمجة الخارجية، لا حساب المعالج وحده.
أما الخيوط الافتراضية و Go و Node.js فلا تحتجز خيطًا أثناء الانتظار، فيختفي هذا القيد تمامًا ويستمر النمو حتى يصطدم بالمعالج أو بعدد المقابس المتاحة.
لكن لـ Node.js تحذير خاص: إذا تجاوز حساب المعالج 20 ميلي ثانية للطلب الواحد، فثمة خطر حجب حلقة الأحداث، وتُظهر الأداة تنبيهًا عند هذا الإعداد. المعنى أن العمليات الحسابية الثقيلة لا تناسب حلقة أحداث وحيدة.
طلبات القراءة التي تُصيب الذاكرة المؤقتة لا تصل إلى قاعدة البيانات إطلاقًا، فينخفض الضغط على بِركة الاتصالات بمقدار نسبتها كاملة.
في الحساب: نسبة القراءة الفعلية تساوي نسبة القراءة مضروبة في (واحد ناقص معدل الإصابة). فإذا كانت القراءة 80% ومعدل الإصابة 50%، فلن يصل إلى قاعدة البيانات سوى 40% من مجموع الطلبات.
ولهذا كلما زادت نسبة القراءة في خدمتك زاد مردود الذاكرة المؤقتة. أما أحمال الكتابة الغالبة فلن يخفّف عنها رفع معدل الإصابة شيئًا، لأن الكتابة تذهب إلى السيّد دائمًا.
وعند اختيار بنية سيّد/تابع، تُوجَّه الكتابة إلى السيّد والقراءة الفعلية إلى النسخ التابعة، ويُحسب لكل جانب سقفه المستقل. زيادة عدد النسخ التابعة تنفع القراءة وحدها.
تفعيل طابور الرسائل يعني افتراض تفويض النداءات الخارجية البطيئة إليه، فتُزال زمن الانتظار الخارجي من مسار الطلب ويُحتسب بدلًا منه 5 ميلي ثانية فقط تكلفةً لإيداع الرسالة في الطابور.
إن كان زمن الواجهة الخارجية 300 ميلي ثانية، فإن الزمن الكلي للطلب ينكمش انكماشًا هائلًا. وفي نموذج الخيوط المحتجزة يتحوّل هذا الفارق مباشرة إلى دوران أسرع للبِركة، فيبدو الأثر أشدّ وضوحًا.
الفائدة الثانية هي الأمان تحت الحمل الزائد: تُحفظ الزيادة عن الطاقة داخل الطابور بدل أن تتكدّس داخل الخادم وتلتهم ذاكرته.
أما بدون طابور، وحين يكون الاختناق في طبقة التطبيق، فتتراكم الطلبات الفائضة اتصالاتٍ منتظرة في الذاكرة. تضيف الأداة هذا الحمل إلى الحساب، وتعلن نفاد الذاكرة إن تجاوز السعة المتاحة.
يقوم التقدير على افتراض أن كل طلب قيد المعالجة يحجز ميغابايتًا واحدًا من الذاكرة. فكلّما ارتفع عدد الطلبات المتزامنة انعكس ذلك مباشرة على الاستهلاك.
يُضاف إلى ذلك أساس ثابت: في نموذج الخيوط 512 ميغابايت زائد ميغابايت لكل خيط، وفي النموذج اللاتزامني 100 ميغابايت لكل نواة معالج. وهنا يتبيّن سبب كون توسيع بِركة الخيوط بلا حساب استنزافًا للذاكرة.
وحين يتجاوز الاستهلاك حجم الذاكرة المتاحة، يتحوّل الاختناق إلى نفاد الذاكرة أيًّا كان المورد المحدِّد قبله. وهذا نمط فشل واقعي: السقف النظري للمعاملات مريح لكن الخادم يسقط بالذاكرة أولًا.
توسيع بِركة الخيوط يرفع TPS ويرفع استهلاك الذاكرة في آن واحد. وإظهار هذه المقايضة بالأرقام هو الغرض الأساسي من الأداة.
هذه محاكاة حسابية بحتة: لا تُرسَل أي طلبات إلى خادم حقيقي، وتُحسب كل الأرقام داخل متصفحك وحده.
النموذج مبسّط عن قصد. فهو لا يعكس توقّفات جامع القمامة، ولا عرض النطاق الشبكي، ولا الإدخال والإخراج على القرص، ولا كلفة تبديل السياق بين الخيوط، ولا تنازع الأقفال وكفاءة الفهارس في قاعدة البيانات.
كما لا يأخذ في الحسبان تفاوت زمن المعالجة بين طلب وآخر. وفي الأنظمة الحقيقية يحدّد الإحساسَ بالبطء زمنُ الذيل (p99) لا المتوسط، ومن هنا ينشأ أكبر فارق بين التقدير والواقع.
لذلك استعمل النتيجة نقطة انطلاق لتحديد المواصفات وترجيح قرار التوسعة، ثم تحقّق نهائيًا باختبار حمل فعلي بأدوات مثل k6 أو JMeter.
لرؤية كيف يطول الطابور ويزيد زمن الاستجابة حين ترتفع الاتصالات المتزامنة.
لا. محاكاة حسابية محلية بلا أي طلبات خارجية.
أساسيات نظرية الطوابير: يُحسب الانتظار من معدل الوصول ومعدل الخدمة.