تشخيص مشكلات أداء WPML – بطء لوحة التحكم، وانتهاء مهلة لوحة إدارة الترجمة، وتأخر استجابة الواجهة الأمامية

تأكيد مكان البطء

• الواجهة الأمامية بطيئة، ولوحة التحكم تعمل جيداً: من المحتمل أن يكون السبب هو إعدادات التخزين المؤقت للصفحة بالكامل أو إضافة تستهلك موارد الواجهة الأمامية بشدة.
• لوحة التحكم بطيئة، والواجهة الأمامية تعمل جيداً: من المحتمل أن يكون السبب هو تضخم التحميل التلقائي في wp_options، أو إضافة ثقيلة تعمل في لوحة التحكم فقط، أو خادم ضعيف الأداء.
• لوحة إدارة الترجمة بطيئة تحديداً: من المحتمل وجود عدد كبير من المقالات في استعلام لوحة التحكم وعدم كفاية ذاكرة PHP أو وقت التنفيذ.
• عمليات الترجمة بطيئة: من المحتمل أن يكون السبب هو الاتصال بخدمات الترجمة؛ تحقق من سجل الاتصالات في WPML ← الدعم.

التحقق من موارد الخادم

افتح WPML ← الدعم. تشير لوحة التحذيرات في الأعلى إلى ذاكرة PHP إذا كانت أقل من 256 MB التي يوصي بها WPML. تحتاج المواقع ذات الكتالوجات الأكبر إلى 512 MB أو أكثر.

أعراض أخرى متعلقة بموارد الخادم:

• استعلامات قاعدة البيانات بطيئة. تستفيد المواقع الكبيرة التي تحتوي على العديد من الترجمات من خادم قاعدة بيانات مدعوم بأقراص SSD، وinnodb_buffer_pool_size كافية، وفهارس على جدول wp_icl_translations (تُضاف هذه الفهارس بواسطة WPML؛ ونادراً ما تحتاج إلى تدخل يدوي).
• وقت تنفيذ PHP. إذا كان max_execution_time أقل من 60 ثانية وانتهت مهلة لوحة التحكم، فقم بزيادته.
• وحدة المعالجة المركزية (CPU). غالباً ما تفرض خطط الاستضافة المشتركة قيوداً صارمة على وحدة المعالجة المركزية؛ تحقق مع شركة الاستضافة الخاصة بك مما إذا كان يتم تقييد مواردك.

التخزين المؤقت للكائنات

يقوم WordPress بدون التخزين المؤقت للكائنات بتحميل العديد من إعدادات WPML من قاعدة البيانات في كل طلب. أضف Redis أو Memcached كذاكرة تخزين مؤقت للكائنات (توفر معظم استضافات WordPress المُدارة هذا الخيار؛ وإذا لم يكن كذلك، فإن إضافتي Redis Object Cache أو WP Redis تتيحان ذلك).

عادةً ما يكون التحسن كبيراً. حيث يتم تقديم الإعدادات التي كانت تتطلب سابقاً استعلامات من قاعدة البيانات مباشرة من الذاكرة.

التخزين المؤقت للصفحة بالكامل

يُعد التخزين المؤقت للصفحة بالكامل (WP Rocket، أو W3 Total Cache، أو التخزين المؤقت الطرفي لمزود الاستضافة) أكبر مكسب للأداء من حيث سرعة الواجهة الأمامية.

إذا كان لديك بالفعل نظام تخزين مؤقت ولكن الصفحات لا تزال تبدو بطيئة، فتحقق مما إذا كان نظام التخزين المؤقت لديك يتعامل بشكل صحيح مع عناوين URL الخاصة بكل لغة. تحتاج بنية عناوين URL في WPML (سواء كانت اللغة كدليل، أو اللغة كنطاق فرعي، أو اللغة كنطاق مستقل) إلى أن يتغير التخزين المؤقت بناءً على عنوان URL. تقوم معظم أنظمة التخزين المؤقت بذلك تلقائياً، ولكن يجدر بك التحقق من عدم تقديم النسخة الفرنسية من التخزين المؤقت للنسخة الإنجليزية أو العكس.

الإضافات المتعارضة أو البطيئة

تتراكم الإضافات في المواقع؛ بعضها مبني بشكل جيد وبعضها الآخر ليس كذلك. للعثور على إضافة بطيئة:

1. ثبّت Query Monitor (إضافة لتصحيح الأخطاء).
2. أعد تحميل صفحة بطيئة.
3. انظر إلى Queries by Component. الإضافة التي تحتوي على الاستعلامات الأكثر استهلاكاً للموارد هي المشتبه بها.

إذا كانت إحدى الإضافات هي السبب، فاستبدلها أو عطّل الميزة الموجودة فيها والتي تسبب البطء.

خدمات الترجمة بطيئة، وليس الموقع

إذا كانت وظائف الترجمة تبدو بطيئة ولكن الموقع نفسه يعمل جيداً، فإن عنق الزجاجة يكمن بين موقعك والبنية التحتية لترجمة WPML.

تحقق من WPML ← الدعم ← سجل الاتصالات. يُظهر السجل زمن الانتقال لكل استدعاء API. إذا كانت الاستدعاءات الفردية تستغرق ثوانٍ عديدة، فإن المشكلة تتعلق بالاتصال (مسار الشبكة، أو DNS، أو تقييد الاتصالات الصادرة من قبل مزود الاستضافة)، وليست في الموقع. أما إذا كان التخزين المؤقت الخاص بـ WPML هو السبب، فإن أدوات استكشاف الأخطاء وإصلاحها الآمنة تتضمن مسح ذاكرة التخزين المؤقت في WPML. عندما يحتاج فحص الأداء إلى مراجعة فريق الدعم، اجمع ما توصلت إليه عبر مشاركة معلومات تصحيح الأخطاء مع الدعم.