تحسين الأداء

منذ الدرس الأول يتكرر عيب واحد: قائمة تُحمَّل باستعلام واحد، ثم يُنفَّذ استعلام لكل عنصر لاستكمال البيانات الناقصة. خمسون طلباً معروضاً تعني مئة واستعلاماً مُرسَلاً. شيفرة Java سليمة، والتعليقات التوضيحية (annotations) هي نفسها الواردة في التوثيق، والاختبارات تنجح. ومع ذلك تستغرق الصفحة ثماني ثوانٍ لتظهر في بيئة الإنتاج.

هذا الفصل هو خاتمة الخيط الرابط. يبدأ بالتشخيص، لأننا لا نستطيع إصلاح ما لا نقيسه، ولأن الحدس يخطئ دائماً في هذه النقطة: فالاستعلام المكلف لا يكون تقريباً أبداً ذلك الذي نشتبه فيه. ثم يعرض الأدوات الثلاث التي تحل مشكلة N+1 — JOIN FETCH و@EntityGraph و@BatchSize — مع المعيار الذي يتيح الاختيار بينها، فهي ليست قابلة للتبادل، ولكل منها حدٌّ صارم.

ثم تأتي الحالة التي لا يعالجها JOIN FETCH: الترقيم (pagination) على مجموعة (collection) محمَّلة. إنه فخ خاص وصامت، يجعل Hibernate يحمّل الجدول بأكمله في الذاكرة بينما يمرّ تحذير خافت في سجلات التشغيل.

ويُختتم الدرس بما لا تعوّضه أي annotation: فهارس PostgreSQL، التي لا ينشئها توليد المخطط، والتي تصبح دونها كل التحسينات السابقة مبنية على مسح تسلسلي للجدول.

التشخيص: عدّ الاستعلامات لا قياسها بالمؤقّت

المؤشر الوحيد الموثوق هو عدد الاستعلامات المُرسَلة في كل وحدة عمل. وHibernate يوفّره.