تجنب كارثة CMS: كيفية منع تعطل موقع الويب

ماذا يعني في الواقع أن يتم اعتبار الموقع معطلاً ؟

في كثير من الأحيان هذا يعتمد على من تسأل.

لكي يتم اعتبار موقع الويب معطلاً ، قد يعني ذلك عددًا من الأشياء المختلفة:

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

بغض النظر عن السبب أو الدرجة ، يمكن أن يكون تأثير تعطل موقع الويب خطيرًا ، من أوامر التجارة الإلكترونية المفقودة وإحباط المستخدمين إلى ضعف ثقة العملاء.

في الجزء الثالث من سلسلة Avoiding CMS Disaster ، نستكشف الأسباب الجذرية الكلاسيكية لتعطل موقع الويب والدور الذي تلعبه المراقبة المستمرة والعوامل الأخرى في تجنب ذلك.

أولاً ، الدور الذي تلعبه المراقبة المستمرة

نحن نراقب الجوانب المختلفة لموقع الويب ، حتى نتمكن من معرفة ما إذا كان هناك شيء لا يعمل بشكل صحيح في أي من الطبقات المختلفة التي تشكل منصة WordPress VIP المدارة بالكامل. هذه الطبقات تشمل:

• اتصال الشبكة
• موازن التحميل
• خوادم الويب
• كائن التخزين المؤقت (Memcached)
• قواعد بيانات
• Elasticsearch
• خدمة الملفات (CDN)

نحاول اكتشاف المشكلات مبكرًا حتى نتمكن من توقع المشكلات المستقبلية التي قد تؤثر على استقرار موقع الويب. تتيح لنا سجلات الإحالة المرجعية من مكونات نظام مختلفة مراجعة الفترات التي تم الإبلاغ فيها عن عدم استقرار موقع الويب. نظرًا لأن مجموعة من العوامل بدلاً من مشكلة واحدة قد تكون مسؤولة عن وقت التوقف عن العمل ، فإننا نستخدم عددًا من الأدوات لمقارنة البيانات عبر كل من الأنظمة والتطبيقات.

في معظم الحالات ، يكون عدم استقرار موقع الويب نتيجة لرمز التطبيق ، أي سمة WordPress المخصصة أو الخارجية ورمز البرنامج المساعد. فيما يلي بعض الأشياء التي نبحث عنها عند التحقق من موقع غير مستقر ، وكيفية التخفيف من كل منها.

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

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

إجابة WordPress VIP:

يوفر WordPress VIP Platform تخزينًا قويًا للصفحة عبر شبكة عالمية من خوادم ذاكرة التخزين المؤقت ، كل منها يستخدم لتخزين وتقديم المحتوى الأقرب إلى المستخدم النهائي. دائمًا ما يكون وقت الاستجابة من خادم ذاكرة التخزين المؤقت على الحافة أسرع من أي شيء يتجاوز التخزين المؤقت للصفحة ويصل إلى الخوادم الأصلية.

تحديات التخزين المؤقت

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

غالبًا ما يمكن العثور على حل وسط حيث يتم تقديم صفحة ثابتة من خلال ذاكرة التخزين المؤقت للحافة ، مع ميزات ديناميكية (مثل حالة تسجيل الدخول ، وعربات التسوق) المضافة عبر JavaScript. يمكن بعد ذلك استخدام الطلبات غير المتزامنة من JavaScript للتواصل مع نقطة نهاية WordPress REST API المصممة بحمل أقل بكثير من تحميل صفحة كاملة.

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

إجابة WordPress VIP:

تحتوي كل بيئة تطبيق WordPress VIP على مجموعة Memcached المخصصة الخاصة بها ، والتي تخزن بيانات ذاكرة التخزين المؤقت للكائنات في الذاكرة لاسترداد سريع وفعال.

عمليات نشر التعليمات البرمجية غير المختبرة

يعد هذا سببًا شائعًا آخر لتعطل موقع الويب ويسهل تشخيصه بناءً على السبب والنتيجة الخالصة.

إذا كان موقع الويب الخاص بك قد نشر للتو رمزًا غير مختبَر ، مما أدى إلى مشكلات فورية في الموقع ، فهناك سبب محتمل. إذا استطعت ، قم بإعادة رمز المشتبه به إلى الإصدار السابق في أسرع وقت ممكن.

ما هو أفضل شيء تفعله لتجنب هذا الموقف؟ اختبر بدقة كل جزء من التعليمات البرمجية في بيئة تطوير أو مرحلة منفصلة قبل إطلاقها للإنتاج.

إجابة WordPress VIP:

نظرًا لأن جميع عمليات نشر موقعنا تتم عبر GitHub ، يمكن لعملاء WordPress VIP بسهولة إعادة الشفرة بأنفسهم ، دون فقد أي تغييرات جديدة في التعليمات البرمجية ، والتي تظل مخزنة بأمان في سجل مراجعة GitHub. اختياريًا ، في حالات الطوارئ ، يمكننا التراجع عن موقع الويب الخاص بالعميل إلى عملية نشر سابقة نيابة عنهم ، بشكل مستقل عن GitHub.

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

أخطاء PHP

يستخدم WordPress كود PHP على الخادم. قد يكون خطأ PHP "فادحًا" ، مما يعني أنه بمجرد حدوث الخطأ ، سيتوقف تشغيل صفحة الويب أو البرنامج النصي أو الأمر. ستظهر هذه الأخطاء دائمًا تقريبًا كأخطاء مرئية في مكان ما ، وسيتم تسجيلها في سجلات PHP.

ملاحظة: بعض تحذيرات PHP في PHP 7 تصبح أخطاء فادحة في PHP 8 ، لذلك من المهم أن تأخذ هذه الأخطاء على محمل الجد.

إجابة WordPress VIP (بالإضافة إلى نصيحة مفيدة):

تقوم منصتنا تلقائيًا بتسجيل جميع أخطاء PHP ، مما يجعلها متاحة لعملاء WordPress VIP في لوحة القيادة الخاصة بهم ولمهندسينا.

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

استعلامات قاعدة بيانات MySQL البطيئة

يستخدم كل موقع ويب WordPress قاعدة بيانات لتخزين محتوى موقع الويب وبيانات التكوين. تجلب استعلامات قاعدة البيانات بيانات المحتوى لصفحات الويب ، ولكن في بعض الأحيان تتم كتابة هذه الاستعلامات بطريقة غير فعالة. قد تعمل بشكل جيد مع المواقع التي تحتوي على بضع مئات من الصفحات فقط ، ولكنها تتوقف عند التعامل مع كميات كبيرة من البيانات (تحتوي بعض مواقع الويب على نظامنا الأساسي على ملايين السجلات المخزنة).

يربط الاستعلام البطيء موارد قاعدة البيانات ، مما قد يؤثر على استقرار الموقع - ليس فقط للصفحة أو البرنامج النصي أو الأمر الذي يقوم بتشغيل SQL ، ولكن عبر التطبيق بأكمله. غالبًا ما تكافح المواقع لأن استعلامات قاعدة البيانات الفردية أو المتعددة تكون بطيئة ، على سبيل المثال ، أي استعلام يستغرق وقتًا أطول من 0.75 ثانية لتنفيذه.

إجابة WordPress VIP:

يساعد WordPress VIP في التخفيف من اختناقات قاعدة البيانات من خلال تزويد كل تطبيق بمجموعة قاعدة بيانات مخصصة تتميز بقاعدة بيانات أساسية ، حيث تحدث جميع استعلامات كتابة قاعدة البيانات ، وقواعد بيانات متماثلة واحدة أو أكثر للقراءة فقط. يؤدي هذا إلى زيادة عدد استعلامات قاعدة البيانات المتزامنة التي يمكن إجراؤها ، مما يؤدي إلى توزيع حمل الموارد عندما يكون الموقع تحت الضغط. ومع ذلك ، لا يمكن دائمًا حل استعلامات قاعدة البيانات البطيئة ببساطة عن طريق إضافة موارد قاعدة بيانات إضافية. لهذا السبب ننصح العملاء بمراقبة استعلامات قاعدة البيانات البطيئة باستخدام Query Monitor و New Relic (المقدمة من نظامنا الأساسي). تُبرز هذه العناصر مكان ظهور الاستعلامات في قاعدة البيانات ، حتى يتمكن فريق التطوير لديك من إعادة تشكيلها لتحسين الأداء.

أخيرًا ، يمكن أن يساعد دعم التطبيقات و Premier Engineers فريقك أيضًا في العثور على هذه الاستعلامات وتحليلها ، واقتراح طرق لتحسينها من أجل السرعة والكفاءة.

يكتب قاعدة بيانات زائدة

في بعض الأحيان ، تقوم ميزة ، مثل التسجيل المخصص أو رمز التتبع ، بتحديث قاعدة البيانات عند كل طلب. يمكن أن يؤدي ذلك إلى عدم الاستقرار لسببين:

• النسخ المتماثلة السابقة لقاعدة البيانات : يتم توجيه جميع استعلامات الكتابة إلى قاعدة البيانات الأساسية ؛ سيتم أيضًا توجيه استعلامات قاعدة البيانات اللاحقة لنفس الجدول (أو الجداول) في نفس طلب الصفحة هناك. من خلال عدم الاستفادة من النسخ المتماثلة لقاعدة البيانات ، فإن هذا يحد من قابلية توسيع الموقع.
• تجاوز التخزين المؤقت للصفحة : لكي تتم كتابة قاعدة بيانات في كل طلب صفحة ، يجب تجاوز التخزين المؤقت للصفحة. لكن القيام بذلك يعني أنه تم اختراق خط الدفاع الأول (والأفضل).

إجابة WordPress VIP:

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

الأسباب الأخرى المعروفة للتوقف عن العمل وكيفية تجنبها

الإضافات

هناك الآلاف من المكونات الإضافية الشائعة والمفيدة للجهات الخارجية في نظام WordPress البيئي والتي توفر ميزات ووظائف رائعة. على الرغم من ذلك ، يواجه البعض تحديات في التوسع ، مما قد يؤدي إلى مشكلات تعطل عند إضافته إلى موقع ويب به الكثير من المحتوى وحركة المرور.

إجابة WordPress VIP:

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

التسجيل المخصص

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

إجابة WordPress VIP:

بالنسبة للعملاء ، نوفر الوصول إلى سجلات PHP القياسية في لوحة Health في لوحة معلومات تطبيق WordPress VIP. هناك يمكنهم تسجيل الأخطاء المخصصة (وكذلك إلى New Relic) ، والتي لن تؤثر سلبًا على قاعدة البيانات.

مكالمات API عن بعد

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

إجابة WordPress VIP:

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

اقرأ المزيد في سلسلة Avoiding CMS Disaster

عندما يكون عملك على المحك ، لا يمكنك إرسال أعمال جديدة إلى مكان آخر وتشويه علامتك التجارية من خلال جعل نظام إدارة المحتوى الخاص بك (CMS) يقدم تجربة رقمية سيئة. في كيفية تحسين أداء موقع الويب ، نقوم بتشخيص خمسة متسببين شائعين في التباطؤ وكيفية تحسين الأشياء باستخدام نظام إدارة محتوى رشيقة.

يجب أن تكون الأيام ذات الازدحام الشديد سببًا للاحتفال ، وليست كابوسًا للمهندسين الذين يحاولون الحفاظ على الموقع والتطبيقات في حالة جيدة للتعامل مع الحمل - وسمعتك سليمة. في Scaling WordPress for High Traffic ، نستكشف أربع طرق لتمكين موقع WordPress على الويب من التعامل مع موجات المد والجزر المرورية.