عندما تستغرق الشاشة 30 ثانية للتحميل أو لا ينتهي التقرير، يزداد الضغط للقيام بشيء ما على الفور. شراء خادم أكبر، أو إجراء تغيير سريع في قاعدة البيانات، أو حفظ نسخة من النتائج لتتحمل بشكل أسرع. قد يساعد أي من هذه الحلول، ولكن دون معرفة سبب البطء، لا يمكنك معرفة ما إذا كان الحل سيدوم، أو ما إذا كان مجرد إخفاء للمشكلة حتى الشهر المقبل.
أفضل النهج الثابت والتدريجي. فهو عادة ما يكون أسرع في النهاية، وأسهل بكثير في الشرح للأشخاص الذين يدفعون تكاليفه.
أولاً، حدد بدقة ما هو البطيء
أبدأ بالتحديد. أي شاشة أو تقرير؟ لأي عميل، أو نطاق تاريخ، أو بحث؟ هل هو بطيء في كل مرة، أم فقط في صباح يوم الاثنين؟ هل قاعدة البيانات مشغولة فعلياً، أم أن التأخير يحدث في مكان آخر تماماً؟
ثم أقوم بقياسه، ليكون هناك رقم "قبل" واضح للمقارنة به بعد كل تغيير. أتوخى الحذر عند الاختبار على النظام المباشر. فشيء غير ضار عند تشغيله مرة واحدة قد يبطئ الجميع عند تشغيله مراراً وتكراراً.
انظر إلى كيفية قيام قاعدة البيانات بالعمل
تقرر قاعدة البيانات بنفسها كيفية العثور على المعلومات التي تطلبها، تماماً مثل شخص يختار مساره عبر مستودع. يمكن لمعظم قواعد البيانات أن تظهر لك المسار الذي اختارته، وغالباً ما يكون الجواب هناك.
أحياناً تقرأ قاعدة البيانات كل سجل في جدول ضخم فقط للعثور على القليل منها. وأحياناً تسيء تقدير حجم البيانات التي تتعامل معها لأن ملاحظاتها الخاصة حول البيانات قديمة. وأحياناً تمنع طريقة كتابة البحث النظام من استخدام اختصار موجود بالفعل. رؤية المسار تخبرك أين يضيع الوقت، لذا يمكنك إصلاح السبب الحقيقي بدلاً من التخمين.
أضف الاختصارات بحذر
الحل الأكثر شيوعاً لقاعدة بيانات بطيئة هو الفهرس (index). إنه يعمل مثل الفهرس في نهاية الكتاب: فهو يسمح لقاعدة البيانات بالانتقال مباشرة إلى السجلات الصحيحة بدلاً من قراءة كل شيء.
لكن الفهارس ليست مجانية. فكل واحد منها يشغل مساحة ويضيف القليل من العمل الإضافي في كل مرة يتم فيها حفظ البيانات أو تغييرها. إضافة الكثير منها قد يسرع تقريراً واحداً بينما يبطئ شاشة الطلبات التي يستخدمها الموظفون طوال اليوم. لذا أنظر إلى ما هو موجود بالفعل وما يفعله النظام في أغلب الأحيان، وأختبر أي تغيير مقابل الاستخدام اليومي المعتاد، وليس فقط التقرير البطيء الواحد.
توقف عن القيام بعمل لا يحتاجه أحد
عدد مدهش من الأنظمة البطيئة تقوم ببساطة بالكثير من العمل. تحميل 5000 سجل لعرض أول 20 منها فقط. جلب كل شيء ثم تصفيته لاحقاً. البحث عن نفس قائمة فئات المنتجات مراراً وتكراراً. القيام برحلة منفصلة إلى قاعدة البيانات لكل سطر في الطلبية بدلاً من الحصول عليها جميعاً دفعة واحدة.
غالباً ما يحدث التخلص من هذا الجهد الضائع الفرق الأكبر. يتطلب هذا عناية، لأن كل تغيير يجب أن يعطي نفس النتائج الصحيحة تماماً كما كان من قبل.
تحقق مما إذا كانت قاعدة البيانات هي السبب حقاً
غالباً ما يتم إلقاء اللوم على قاعدة البيانات، لكن التأخير يمكن أن يكون في أي مكان بين النقرة على الشاشة وظهور النتيجة. قد يكون التطبيق ينتظر دوره مع قاعدة البيانات، أو يرسل الكثير من البيانات عبر الشبكة، أو يقضي وقتاً طويلاً في إعداد الصفحة.
لذا أقوم بتوقيت كل خطوة على حدة. بعد الإصلاح، أتحقق من أنه يصمد عندما يستخدم الكثير من الأشخاص النظام في وقت واحد، وليس فقط في فترة هادئة. وأدون ما تغير ولماذا، حتى إذا تباطأ النظام مرة أخرى لاحقاً، يعرف الشخص التالي أين يبحث.
النهج في سطر واحد
جده، قسه، غير شيئاً واحداً، ثم قسه مرة أخرى. الهدف ليس جعل تقرير واحد يبدو مثيراً للإعجاب، بل جعل النظام أسرع للجميع، دون كسر أي شيء على طول الطريق.