سؤال

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

وحتى الآن، فإن أفضل الاستدلال أنا وضعت للمقارنة بين التوقعات استخدام (عدد المستخدمين المسجلين والمتزامنة أن التطبيق يجب حضور) مع البيانات التي تم جمعها في المنشآت الموجودة لدينا. شيء من هذا القبيل: إذا حضر تركيب A 100 المستخدمين المتزامنين مع X الأجهزة، ثم تركيب B تحتاج 2 * X الأجهزة لحضور 200 المستخدمين المتزامنين

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

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

هل كانت مفيدة؟

المحلول

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

ومن الناحية المثالية، الأولي للشراء HW / SW هو لتثبيت التجريبية، وكنت القياسي الإعداد الطيار مرة واحدة والأمر متروك والمواصفات الاجتماع. استخدام تلك النتائج لمشروع الاحتياجات القدرة على الانتقال من الطيار للإنتاج. وبطبيعة الحال، وهذا يتطلب وقتا في جدول التجريبية إلى الإنتاج لقياس التطبيق ثم النظام واتخاذ تسليم المعدات. لكنها ستعطي تقدير قدرة أكثر دقة من فعل كل ذلك مقدما.

نصائح أخرى

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

وأود أن أقترح بيئة VM حيث يمكن بسهولة إضافة وحدة المعالجة المركزية والذاكرة بناء على احتياجات التطبيق، إلى جانب بعض واقعية خارجية تحميل / مقياس اختبار باستخدام خدمة مثل watchmouse أو browsermob.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top