تعتبر سرعة قاعدة البيانات من أهم العناصر المؤثرة بشكل مباشر على أداء وسرعة أي متجر Magento 2؛ فهي ما يُقرر مدى سرعة إظهار المنتجات والتصنيفات والمحتوى والأسعار وحتى عمليات الاستدعاء المختلفة مثل الإضافة للسلة، الحذف من السلة، تحديث طرق الشحن وغيرها.
في دراسة الحالة هذه سنتعرف على خطوات تحسين سرعة صفحات التصنيفات في ماجنتو 2، مع أمثلة عملية على الخطوات التي قمنا بتنفيذها من أجل ضمان خفض زمن تحميل صفحات التصنيفات.
مع ضرورة الملاحظة أنه في غالبية الحالات بكون السبب هو بطئ استعلامات SQL بسبب عدم ملائمتها لقواعد كتابة الإستعلامات السليمة، أو من الممكن أن يكون السبب هو اعتماد إعدادات MySQL/MariaDB الإفتراضية والتي لا تناسب حجم البيانات الموجودة على المتجر.
محتويات المقال
التحديات التي واجهناها
| التحدي/عامل الخطر | النتيجة قبل التحسين |
|---|---|
| زمن تحميل صفحة التصنيف (LCP) | 3.6 ثانية |
| استهلاك MySQL للمعالج CPU (في اوقات الذروة) | 90٪ |
| استعلامات بطيئة (بوقت تنفيذ أكبر من 2 ثانية) | 1,450 يومياً |
| اقتراح الشركة التقنية السابقة | ترقية الخادم من t3.medium إلى t3.large |
خطوات تحسين سرعة صفحات التصنيفات في ماجنتو 2
| الخطوة | الحل | الأثر المباشر للحل |
|---|---|---|
| تسجيل الاستعلامات | تفعيل تخزين استعلامات قواعد البيانات من خلال تعيين debug true في ملف env.php؛ بحيث يتم حفظ سجل الإستعلامات في var/debug/db.log | بعد التفعيل تم الكشف عن 17 استعلامًا بوقت تنفيذ يتجاوز 3 ثوان للإستعلام الواحد. |
| تحليل & EXPLAIN | EXPLAIN + ملف slow query log | تم تحديد استعلام الربط في جدول catalog_category_product_index كأبطأ استعلام SQL |
| إضافة فهارس مركّبة | SQL ALTER TABLE catalog_category_product_index ADD INDEX idx_cat_pos (category_id, position); | تم خفض وقت الاستعلام الرئيسي 62٪ مباشرة بعد إضافة الفهارس. |
| ضبط InnoDB | تحديث الإعدادات وتعيين innodb_buffer_pool_size إلى 60٪ من استهلاك الذاكرة RAM | قلّ استخدام I/O العشوائي 35٪ |
| تهيئة المعاملات | innodb_flush_log_at_trx_commit = 2, innodb_buffer_pool_instances = 4, إيقاف Query Cache (مستحسن لماجنتو 2) | قلّ زمن الـ COMMIT والتجزيء |
| إعادة جدولة الـIndexers | تغيير وضع الفهرسة إلى”On Save” للفئات الضخمة، وجدولة فهرسة الساعة 3 فجراً من كل يوم لتجنب التعارضات بين الفهرسة عند الحفظ والفهرسة المجدولة. | اختفت قمم CPU أثناء ساعات الذروة بشكل شبه كُلي. |
| تركيب وضبط المراقبة الآلية | تم استخدام New Relic مع تنبيهات مباشرة لموظفينا في حال تجاوز استهلاك المعالج CPU قيمة 70٪ أو أكثر. | سنتمكن بهذه الطريقة من معالجة إية استعلامات أو أخطاء مؤثرة بشكل مباشر على استهلاك الموارد. |
النتيجة بالأرقام
| المؤشر | قبل | بعد |
|---|---|---|
| LCP صفحات التصنيفات | 3.6 ث | 1.6 ث (-55 ٪) |
| TTFB المتوسّط | 920 مللي ثانية | 410 م ث (-55 ٪) |
| استعلامات بطيئة / يوم | 1,450 | 310 (-79 ٪) |
| استهلاك CPU MySQL (وقت الذروة) | 90٪ | 63٪ (-30 ٪) |
لماذا يجب عليك تطبيق هذه التحسينات؟
- زيادة معدل التحويل — كل ثانية تأخير بعد الثلاث الأولى تُخفض معدل الشراء 7٪.
- تأجيل ترقية السيرفر — تخفيض استهلاك الموارد في أوقات الذروة يمنع إنفاق مئات الدولارات سنويًّا على موارد لا حاجة لها.
- أمان واستقرار أعلى — استعلامات أقصر تعني فرصًا أقل لقفل الجداول Lock وظهور أخطاء 500 internal server error في أوقات الذروة.
- تحسين السيو SEO — كلما تحسنت سرعات LCP وTTFB سيكون لديك فرصة أفضل لرفع ترتيب صفحات متجرك في نتائج Google SERP.
خطوات قابلة للتطبيق في متجرك
- فعّل تسجيل الاستعلامات ثم تفقد
var/debug/db.log. - استخدم
EXPLAINعلى أبطئ 10 استعلامات؛ أضف الفهارس أو أعد كتابة أكواد JOIN. - قم بضبط
innodb_buffer_pool_size ثم أعد تشغيل خدمة MySQL/MariaDB. - راجع جدول
catalogsearch_fulltext؛ إذا تخطى 5 GB فكر بتقسيم الجدول أو استخدام Elasticsearch محسن مع إعداد Heap=50٪. - راقب مؤشرات الأداء كل أسبوع، ولا تفعل أي فهارس جديدة في أوقات الذروة.
الخلاصة
تحسين قاعدة البيانات واستعلاماتها في ماجنتو 2 لا يتطلب ترقية الخادم -السيرفر-؛ بل يبدأ بتسجيل الاستعلامات، تحليلها، وضبط InnoDB بذكاء.
خلال سبعة أيام فقط مع المتابعة والمراقبة، خفضنا زمن تحميل صفحات التصنيفات 55٪، وخفضنا الضغط على المعالج 30٪، ووفرنا على العميل تكلفة ترقية السيرفر، ويمكنك تكرار هذه الحلول في أي متجر يعمل على ماجنتو 2.
والآن… هل ترغب في متجر يعمل بلا أعطال تقنية وبأفضل أداء؟ [تصفح باقات الدعم الفني والصيانة للمتاجر الإلكترونية]
