تخطيط السعة تحديد ما إذا كان النظام يمكنه التعامل مع الحمل

Question

دعنا نقول أن موقع التجارة الإلكترونية القائم على Java EE يعمل بشكل جيد يمنح وقت الاستجابة المتوقع والإنتاجية. يخضع موقع الويب لتغييرات كبيرة في واجهة المستخدم ومن المتوقع أن يجلب 3 مرات حركة المرور.

كيف يمكنني معرفة ما إذا كان يمكن التعامل مع حركة المرور المتوقعة من قبل البيئة الحالية؟

هل هناك طريقة لمعرفة ذلك باستخدام بعض الصيغة التجريبية دون تحميل بالفعل اختبار النظام إذا كان لدي استخدام النظام (وحدة المعالجة المركزية ، استخدام الذاكرة) ، الإنتاجية ، وقت استجابة النظام الحالي. (الهدف هو تحديد ما إذا كان يمكن تلبية SLAs في مرحلة التصميم نفسها)

Answer 1

لا ، لا توجد صيغة لهذا ، هناك الكثير من العوامل المتبادلة لهذا. الطريقة الوحيدة للحصول على أرقام واقعية هي الاختبارات التجريبية. إذا لم تتمكن من القيام بذلك ، فأنت فقط هو الخيار هو الذهاب إلى القدرة المفرطة في الأجهزة والقيام بتخمين متعلم من شأنه أن يذهب شيء من هذا القبيل:

• هل يؤثر واجهة المستخدم الجديدة على استخدام وحدة المعالجة المركزية؟
• هل يستغرق الأمر وقتًا أطول لتقديم ونقل صفحة؟ تقدير الزيادة في التزامن.
• هل يعني المزيد من حركة المرور أيضًا المزيد من البيانات؟ إذا كانت الإجابة بنعم ، فكيف يؤثر هذا على الأداء؟
• هل هناك أي اختناقات يمكن أن تؤدي إلى زيادة غير متوقعة في التزامن؟
• كيف تؤثر زيادة التزامن على استخدام الذاكرة؟
• كيف يؤثر استخدام الذاكرة على ذاكرة التخزين المؤقت لنظام الملفات ، ذاكرة التخزين المؤقت لقاعدة البيانات ، ذاكرة التخزين المؤقت JPA ، إلخ.
• هل الأداء IO مقيد؟ وكم قدرة الاحتياط المتاحة؟
• هل وحدة المعالجة المركزية الأداء ملزمة؟ وكم قدرة الاحتياط المتاحة؟
• ما مقدار السعة الاحتياطية في الذاكرة لديك؟

Answer 2

أنا لا أوافق جزئيا مع الإجابة السابقة. من المؤكد أن أي تخطيط للسعة ينطوي على إنشاء نموذج مع مجموعة من الافتراضات (المحتملة الخطرة).

ومع ذلك ، فإن وجود منظور تاريخي جيد لـ:

• تحميل المعاملات (على سبيل المثال ضربات الويب على سجلات Apache)

• وحدة المعالجة المركزية واستخدام الذاكرة

يمكن بناء تحليلات الأداء المحملة لتحديد "الطلب على الخدمة" (تحدث تقريبًا مقدار الموارد المستخدمة لمعالجة طلب واحد) من خلال التقنيات الإحصائية التحليلية. يمكن بعد ذلك تغذية المعلمة نفسها في طرازات قائمة الانتظار لتقدير وقت الاستجابة المتوقعة والإنتاجية (يمكن أن يصبح سلوكه غير خطير للغاية في مستويات عالية من تشبع الموارد).

على الرغم من ما قاله للتو: - إنها ليست صيغة سهلة

• عليك أن تفترض أن تأثير واجهة المستخدم الجديد هو توليد 3x تحميل ولا شيء آخر (نفس الطلب على الخدمة على الطلب ، نفس الكفاءة)

• أنت تتعرض لخطر تواجه مشكلات مع الاختناقات المحتملة غير المعلنة (مثل تجمعات الاتصال المشبعة ، عرض النطاق الترددي للشبكة ، ...) وهي مشكلة عامة في تخطيط السعة.

الاختبار هو الخيار الآمن الوحيد ، وللأسف خيار غير متوفر.