الكمون شبكة قاعدة البيانات

Question

أنا أعمل حاليًا على نظام n-tier وأواجه بعض مشكلات أداء قاعدة البيانات.أحد المجالات التي قمنا بالتحقق منها هو زمن الوصول بين خادم قاعدة البيانات وخادم التطبيقات.في بيئة الاختبار الخاصة بنا ، يوجد متوسط ​​أوقات بينغ بين المربعين في منطقة 0.2 مللي ثانية ولكن على موقع العملاء أكثر في منطقة 8.2 مللي ثانية.هل هذا شيء يجب أن نكون قلقين بشأنه؟

بالنسبة لنظامك المتوسط، ما الذي تعتبره يا رفاق زمن استجابة معقولًا وكيف يمكنك إجراء اختبار/قياس زمن الوصول؟

كارل

Answer 1

باختصار :لا !

ما يجب عليك مراقبته هو الأداء العام لاستفساراتك (أي النقل إلى قاعدة البيانات + التنفيذ + النقل مرة أخرى إلى الخادم الخاص بك)

ما يمكنك فعله هو استخدام عداد الأداء لمراقبة الوقت الذي يستغرقه تنفيذ استعلاماتك عادةً.من المحتمل أن ترى نتائجك قد تجاوزت مساحة المللي ثانية.

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

Answer 2

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

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

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

وعلى الأرجح، إذا كنت تقوم بتشغيل استعلام واحد، فإن إضافة 8 مللي ثانية للحصول على الرد من قاعدة البيانات لن يكون مهمًا.ولكن إذا كنت تجري 10000 استعلام، وهو ما يحدث بشكل عام مع تعليمات برمجية سيئة أو استخدام غير محسن لـ ORM، فسيتعين عليك الانتظار 80 ثانية إضافية للحصول على اختبار اتصال مدته 8 مللي ثانية، بينما بالنسبة لاختبار اتصال مدته 0.2 مللي ثانية، ستنتظر 4 ثوانٍ فقط.

كسياسة بالنسبة لي، لا أسمح مطلقًا لتطبيقات العميل بالاتصال بقاعدة البيانات مباشرة.أطلب أن تمر تطبيقات العميل دائمًا عبر خادم التطبيقات (على سبيل المثال، خدمة ويب REST).بهذه الطريقة، إذا واجهت عن طريق الخطأ مشكلة ORM "1+N"، فلن يكون الأمر بنفس التأثير.سأظل أحاول حل المشكلة الأساسية..

Answer 3

على خادم يعمل بنظام التشغيل Linux، يمكنك اختبار تأثير زمن الوصول بنفسك باستخدام الأمر tc.

على سبيل المثال، سيضيف هذا الأمر تأخيرًا قدره 10 مللي ثانية لجميع الحزم التي تمر عبر eth0

tc qdisc add dev eth0 root netem delay 10ms

استخدم هذا الأمر لإزالة التأخير

tc qdisc del dev eth0 root

المزيد من التفاصيل متوفرة هنا:http://devresources.linux-foundation.org/shemminger/netem/example.html

ستختلف جميع التطبيقات، لكنني رأيت بالتأكيد مواقف كان لزمن الوصول فيها 10 مللي ثانية تأثير كبير على أداء النظام.

Answer 4

قال أحد المسؤولين الرئيسيين في موقع Answers.com وفقًا لدراساتهم، إن وقت الانتظار البالغ 400 مللي ثانية لتحميل صفحة الويب هو الوقت الذي يبدأون فيه لأول مرة في حث الأشخاص على إلغاء تحميل الصفحة والانتقال إلى مكان آخر.نصيحتي هي إلقاء نظرة على العملية برمتها، بدءًا من طلب العميل الأصلي وحتى تلبية الطلب، وإذا كنت تقوم بعمل جيد هناك، فلن تكون هناك حاجة لمزيد من التحسين.8.2 مللي ثانية مقابل 0.2 مللي ثانية أكبر بشكل كبير من الناحية الرياضية، ولكن من الناحية الإنسانية، لا يمكن لأحد أن يدرك حقًا وجود فرق قدره 8.0 مللي ثانية.لهذا السبب لديهم صور نهائية في السباقات ;)