آثار حِمل النظام في الأداء
غالباً ما يتوقف التفكير في كيفية تعريف فهرس متعدد الأعمدة بمجرد استخدام الفهرس في الاستعلام الذي نضبطه. غير أن المُحسِّن لا يستخدم الفهرس لأنه «الصحيح» للاستعلام، بل لأنه أكفأ من المسح الكامل للجدول. وهذا لا يعني أنه الفهرس الأمثل للاستعلام.
وقد أظهر المثال السابق صعوبات إدراك ترتيب الأعمدة الخاطئ في خطة التنفيذ؛ فكثيراً ما تكون معلومات المُسندات مخفية جيداً بحيث يجب البحث عنها تحديداً للتحقق من الاستخدام الأمثل للفهرس.
فمثلاً، لا يعرض SQL Server Management Studio معلومات المُسندات إلا كتلميح عند تمرير مؤشر الفأرة فوق عملية الفهرس («hover») — وكذلك على هذه الصفحة. وتستخدم خطة التنفيذ التالية الفهرس SCALE_SLOW، ومن ثمّ تعرض الشرط على ID2 كمُسند ترشيح («Predicate» فقط، دون Seek).
والحصول على معلومات المُسندات من خطة تنفيذ MySQL أو PostgreSQL أكثر إزعاجاً. وفي الملحق أ التفاصيل.
ومهما بدت معلومات المُسندات تافهة في خطة التنفيذ، فلأثرها في الأداء أهمية كبيرة — وبخاصة عندما ينمو النظام. وتذكّر أن ما ينمو ليس حجم البيانات فحسب بل معدل الوصول أيضاً؛ وهذا معامل آخر من معاملات دالة قابلية التوسع.
إن أعجبك هذا الموضوع، قد يعجبك أيضاً…
… أن تشترك في القوائم البريدية، وتحصل على ملصقات مجانية، وتشتري كتابي، أو تنضم إلى دورة تدريبية.
يرسم الشكل 3.4 زمن الاستجابة بدلالة معدل الوصول — مع بقاء حجم البيانات دون تغيير. وهو يعرض زمن تنفيذ الاستعلام نفسه كما في السابق ويستخدم دائماً القسم ذا أكبر حجم بيانات؛ ويعني ذلك أن النقطة الأخيرة من الشكل 3.2 تقابل النقطة الأولى في هذا المخطط.
الشكل 3.4 قابلية التوسع حسب حِمل النظام
يرسم الخط المتقطع زمن الاستجابة عند استخدام فهرس SCALE_SLOW. وهو ينمو حتى 32 ثانية إذا كانت هناك 25 استعلاماً يعمل في الوقت نفسه. وبالمقارنة مع زمن الاستجابة بلا حِمل خلفي — كما قد تكون الحال في بيئة التطوير لديك — فهو يستغرق 30 ضعفاً. وحتى لو كانت لديك نسخة كاملة من قاعدة بيانات الإنتاج في بيئة التطوير، فقد يظل الحِمل الخلفي سبباً في عمل الاستعلام أبطأ بكثير في الإنتاج.
أما الخط المتصل فيعرض زمن الاستجابة عند استخدام فهرس SCALE_FAST — وليس له أي مُسندات ترشيح. ويبقى زمن الاستجابة أقل بكثير من ثانيتين حتى إذا كان هناك 25 استعلاماً يعمل تزامنياً.
ملاحظة
فحص خطة التنفيذ بعناية يمنح ثقة أكثر من اختبارات الأداء السطحية.
ويبقى اختبار الإجهاد الكامل جديراً بالجهد — لكن كلفته عالية.
كثيراً ما يُستهان بأزمنة الاستجابة المشبوهة أثناء التطوير، ويرجع ذلك في معظمه إلى توقعنا أن «عتاد الإنتاج الأقوى» سيقدّم أداءً أفضل. غير أن العكس هو الحال في أكثر الأحيان، لأن بنية الإنتاج التحتية أكثر تعقيداً وتراكم أزمنة استجابة لا تحدث في بيئة التطوير. وحتى عند الاختبار على بنية مكافئة لبنية الإنتاج، قد يظل الحِمل الخلفي سبباً في أزمنة استجابة مختلفة. وسنرى في القسم التالي أنه ليس من المعقول عموماً توقع استجابات أسرع من «عتاد أكبر».
روابط
- مقال «زمن الاستجابة: الأمان مقابل الأداء» عن أزمنة الاستجابة في البنى التحتية المعقدة.
- مقال: «نعاني حِملاً كبيراً جداً. لنضف خادماً جديداً» لـJams Golick.