فرز مشكلات أداء WPML – بطء لوحة التحكم، وانتهاء مهلة لوحة إدارة الترجمة، وتأخر الواجهة الأمامية
تعود مشكلات أداء WPML (بطء صفحات لوحة التحكم، أو تأخر الواجهة الأمامية، أو انتهاء مهلة لوحة إدارة الترجمة) في الغالب إلى أحد العوامل الشائعة القليلة. تستعرض هذه الصفحة تلك العوامل بالترتيب الذي يجب التحقق منه، قبل أن تفترض أن المشكلة تكمن في 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). غالباً ما تفرض خطط الاستضافة المشتركة قيوداً صارمة على وحدة المعالجة المركزية؛ تحقق مع شركة الاستضافة الخاصة بك عما إذا كان يتم تقييد مواردك.
- بطء في استعلامات قاعدة البيانات. تستفيد المواقع الكبيرة التي تحتوي على العديد من الترجمات من خادم قاعدة بيانات مدعوم بأقراص SSD، وقيمة
-
التخزين المؤقت للكائنات
يقوم WordPress بدون التخزين المؤقت للكائنات بتحميل العديد من إعدادات WPML من قاعدة البيانات مع كل طلب. أضف Redis أو Memcached كذاكرة تخزين مؤقت للكائنات (توفر معظم شركات استضافة WordPress المدارة هذا الخيار؛ وإذا لم يكن كذلك، فإن إضافتي Redis Object Cache أو WP Redis تُمكّنان ذلك).
عادةً ما يكون التحسن كبيراً. حيث يتم تقديم الإعدادات التي كانت تتطلب سابقاً استعلامات من قاعدة البيانات من الذاكرة مباشرة.
-
التخزين المؤقت للصفحة بالكامل
يُعد التخزين المؤقت للصفحة بالكامل (WP Rocket، أو W3 Total Cache، أو التخزين المؤقت الطرفي من مزود الاستضافة) أكبر مكسب أداء لسرعة الواجهة الأمامية.
إذا كان لديك بالفعل نظام تخزين مؤقت ولكنك لا تزال تشعر ببطء الصفحات، فتحقق مما إذا كان التخزين المؤقت يتعامل بشكل صحيح مع عناوين URL لكل لغة. يتطلب هيكل عناوين URL في WPML (سواء كان اللغة كدليل، أو اللغة كنطاق فرعي، أو اللغة كنطاق) أن يتغير التخزين المؤقت بناءً على عنوان URL. تقوم معظم أنظمة التخزين المؤقت بذلك تلقائياً، ولكن يجدر بك التحقق من أن النسخة الفرنسية لا يتم تقديمها من التخزين المؤقت للنسخة الإنجليزية أو العكس.
-
الإضافات المتعارضة أو البطيئة
تتراكم الإضافات في المواقع؛ بعضها مبني بشكل جيد والبعض الآخر ليس كذلك. للعثور على إضافة بطيئة:
- ثبّت Query Monitor (إضافة لتصحيح الأخطاء).
- أعد تحميل صفحة بطيئة.
- انظر إلى Queries by Component. الإضافة التي تحتوي على الاستعلامات الأكثر استهلاكاً للموارد هي المشتبه به.
إذا كانت إحدى الإضافات هي السبب، فاستبدلها أو عطّل الميزة الموجودة فيها والتي تسبب البطء.
-
بطء في خدمات الترجمة، وليس في الموقع
إذا كنت تشعر ببطء في مهام الترجمة ولكن الموقع نفسه يعمل جيداً، فإن عنق الزجاجة يكمن بين موقعك والبنية التحتية لترجمة WPML.
تحقق من WPML > الدعم > سجل الاتصالات. يعرض السجل زمن الوصول لكل استدعاء API. إذا كانت الاستدعاءات الفردية تستغرق ثوانٍ عديدة، فإن المشكلة تتعلق بالاتصال (مسار الشبكة، أو DNS، أو تقييد البيانات الصادرة من مزود الاستضافة الخاص بك)، وليس الموقع. أما إذا كان التخزين المؤقت الخاص بـ WPML هو السبب، فإن أدوات استكشاف الأخطاء وإصلاحها الآمنة تتضمن مسح الذاكرة المؤقتة في WPML. عندما يحتاج فحص الأداء إلى تدخل فريق الدعم، اجمع ما وجدته عبر مشاركة معلومات تصحيح الأخطاء مع الدعم.