تحسين الأداء

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

ينشأ هذا الفارق من ثلاثة اختلافات لا تعيد بيئة التطوير إنتاجها. أولها الحجم: فالربط (join) بلا فهرس يكلّف الثمن نفسه على ثلاثين سطراً، لكنه يتحول إلى مسح كامل على ثلاثة ملايين سطر. وثانيها زمن الاستجابة الشبكي: إذ ينتقل استعلام SQL من 0.1 ms محلياً إلى 2 ms نحو خادم بعيد، فتنتقل عملية تُطلق مئتي استعلام من عشرين ميلي ثانية إلى أربع ثوانٍ. وثالثها التزامن: فما يسير جيداً مع مستخدم واحد قد يستنزف مجمّع الاتصالات مع خمسين مستخدماً.

الإغراء أمام واجهة بطيئة هو إضافة التخزين المؤقت. وهو سابق لأوانه في الغالب: فالتخزين المؤقت يخفي العَرَض، ويعقّد إبطال المحتوى، ويُدخل حالات عدم اتساق، ولا يصلح أي شيء. قبل التحسين نقيس؛ وقبل التخزين المؤقت نعالج السبب. وفي واجهة Spring نموذجية، يكون السبب في ثلاث حالات من أربع هو عدد استعلامات SQL المنفَّذة، لا مدة كل استعلام على حدة.

يشخّص هذا الدرس biblio-api ويصلحها وفق هذا الترتيب: القياس، ثم إزالة N+1، ثم عدم تحميل سوى الضروري، وبعد ذلك فقط التخزين المؤقت وضبط الأحجام والضغط.