إسقاط استعلامات قاعدة البيانات المتزامنة

Question

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

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

السؤال الذي طرحته من الناس في البنية التحتية هو "عدد المستخدمين المتزامنين". دعونا لا نناقش الأساس المنطقي للبحث عن هذا الرقم الوحيد ؛ إنه فقط ما تم طلبه في هذه الحالة!

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

1. إجمالي الجمهور
2. جلسات متزامنة
3. الطلبات المتزامنة
4. استفسارات DB في وقت واحد

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

هذا أمر أساسي للغاية ، وأنا متأكد من أن هناك إرشادات أكثر شمولاً هناك. إذا كان بإمكان أي شخص مشاركة مقاربته في هذا التمرين أو توجيهي إلى موارد أخرى قد تجعل العملية أقل قليلاً ، فسيكون ذلك رائعًا!

Answer 1

سأحاول ، ولكن من الواضح دون معرفة التفاصيل ، من الصعب جدًا تقديم نصيحة دقيقة.

بادئ ذي بدء ، ربما يكون شباب البنية التحتية قد طرحوا هذا السؤال من منظور الترخيص (يمكن ترخيص SQL Server لكل مستخدم أو لكل وحدة المعالجة المركزية)

الان عد الى سؤالك. "جمهور إجمالي" مهم إذا تمكنت من التنبؤ/تحديد هذا الرقم. يمكن أن يمنحك هذا أسوأ سيناريو للحالة عندما يضرب جميع المستخدمين قاعدة البيانات في وقت واحد (على سبيل المثال 9 صباحًا عندما يقوم الجميع بتسجيل الدخول).

إذا قمت بتخزين معلومات الجلسة ، فربما يكون لديك اتصالان على الأقل لكل مستخدم (جلسة واحدة + 1 DB الرئيسية). ولكن يمكن تخفيض هذا الرقم (في بعض الأحيان بشكل ملحوظ) عن طريق تجميع الاتصال (يعتمد على كيفية الاتصال بقاعدة البيانات). استخدم أسوأ سيناريو - 50 اتصال نظام + 2 * عدد المستخدمين.

تعتمد الطلبات/الاستفسارات المتزامنة على طبيعة التطبيق. بحاجة إلى مزيد من التفاصيل. المزيد من الطلبات المتزامنة (إلى الواجهة الأمامية) لن تترجم بالضرورة إلى المزيد من الطلبات في النهاية الخلفية.

بعد قول كل ذلك - لأغراض التكلفة ، تحتاج إلى التركيز على صورة أكبر.

1. سوف يكلفني ترخيص SQL Server (إذا كانت ذاكرتي بشكل صحيح) ~ 128K AUD (XEON المزدوج). الاستعداد الساخن/الدافئ؟ ضعف التكلفة.

2. تخزين القرص - ما مقدار التخزين الذي ستحتاجه؟ الأقراص رخيصة نسبيًا ولكن إذا كنت ستستخدم SAN ، فقد تصبح التكلفة ملحوظة. أيضا - كلما زادت الأقراص كلما كان ذلك أفضل من منظور الأداء.