نظرة على مكدس خادم WordPress الحديث

هل تتذكر متى كان بإمكانك تشغيل موقع WordPress "سريع" باستخدام خادم Apache و PHP فقط؟ نعم، كانت تلك الأيام! كانت الأمور أقل تعقيدًا في ذلك الوقت.

الآن ، كل شيء يجب أن يتم تحميله بسرعة البرق! لم يكن لدى الزائرين نفس التوقعات بشأن أوقات التحميل كما اعتادوا. يمكن أن يكون لموقع الويب البطيء آثار خطيرة عليك أو على عميلك.

مزيد من القراءة على SmashingMag:

• الأذونات المناسبة لنظام ملفات WordPress والملكية
• نقل موقع WordPress دون عناء
• كيفية تطوير WordPress محليًا باستخدام MAMP
• افعل ذلك بنفسك طرق التخزين المؤقت باستخدام WordPress

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

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

ملخص

قبل التعمق ، دعنا نصغر وننظر إلى الصورة الكبيرة. كيف تبدو حزمة خادم WordPress الجديدة هذه؟ حسنًا ، ها هي الإجابة:

يقدم الرسم البياني أعلاه نظرة عامة جيدة على شكل مكدس خادم WordPress الحديث. على مستوى عالٍ ، يمكننا تقسيم ما يحدث إلى ثلاثة مجالات:

• دورة الطلب والرد بين المتصفح و WordPress ؛
• WordPress (وهو برنامج نصي ينفذه وقت تشغيل PHP) ؛
• دورة نتائج الاستعلام بين WordPress وقاعدة بيانات MySQL.

يتمثل دور مكدس خادم WordPress الحديث في تحسين هذه المجالات الثلاثة. هذه التحسينات هي التي تجعل كل شيء يتم تحميله بشكل أسرع. وأفضل جزء هو أن هناك عدة طرق للقيام بذلك. (ياي!)

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

دورة الطلب والاستجابة

كل شيء يبدأ بالمتصفح. لنفترض أنك تريد عرض الصفحة الرئيسية لـ modern.wordpress-stack.org . سيبدأ متصفحك بإرسال طلب HTTP إلى خادم الويب الذي يستضيفه. في الطرف الآخر ، سيأخذ خادم الويب طلبك ويحوله إلى استجابة HTTP.

يجب أن تكون هذه الاستجابة الأولى دائمًا محتوى HTML للصفحة الرئيسية modern.wordpress-stack.org (ما لم يكن هناك خطأ). ومع ذلك ، لم يتم الانتهاء من مهمة المتصفح الخاص بك. لا ، لا تزال هذه الصفحة الرئيسية بحاجة إلى المزيد من الملفات ، وأكثرها شيوعًا هي ملفات CSS و JavaScript وملفات الصور.

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

الآن ، هذا تبسيط واضح ، لكنه كيف تعمل الأشياء لغالبية مواقع WordPress.

تحسين دورة الطلب والاستجابة

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

المكدس موجود لأنه لا يمكنك فقط جعل خادم الويب أسرع. خادم الويب هو أيضًا مرسل. يمكنه تلقي طلب وإرساله فقط إلى خدمات أخرى.

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

• تلقي أقل عدد ممكن من الطلبات ،
• توجيه أقل عدد ممكن من الطلبات إلى PHP.

يركز مكدس خادم WordPress الحديث على هذا الأخير. يريد إعادة توجيه أقل عدد ممكن من الطلبات إلى PHP. سيكون هذا هو الهدف الرئيسي لتحسين المكدس.

نركز على الهدف الثاني لأن المكدس لا يمكنه فعل الكثير فيما يتعلق بالهدف الأول ؛ ليس لها تأثير مباشر عليها. الثاني يتم تناوله إما عن طريق تكوين خادم الويب أو عن طريق تقنيات التطوير الحديثة.

عناصر المكدس لدورة الطلب والاستجابة

إذن ، ما هي عناصر المكدس التي ستساعدنا في تقليل الطلبات المحالة إلى PHP؟ حسنًا ، سيساعدنا عنصران مكدس على وجه الخصوص في تحقيق هذا الهدف: خادم الويب وذاكرة التخزين المؤقت لـ HTTP.

قاعدة بيانات للانترنت

لقد تحدثنا كثيرًا عن خوادم الويب بالفعل. هناك ثلاثة لاعبين كبار في مساحة خادم الويب:

• اباتشي
• خدمات معلومات الإنترنت (IIS)
• nginx

تشكل هذه معًا أكثر من 90٪ من الحصة السوقية لخوادم الويب على الإنترنت. سنركز على Apache و nginx. بينما يمكن استخدام IIS لتشغيل WordPress ، إلا أنه ليس شائعًا لأنه متاح فقط لنظام Windows ، ومعظم خوادم WordPress تستخدم Linux.

هذا يتركنا مع Apache و nginx. طوال عمر WordPress ، كان Apache هو خادم الويب الموصى به. كان لدينا حزمة LAMP (Linux و Apache و MySQL و PHP) ، والتي تقوم بتشغيل WordPress على كل من الكمبيوتر والخادم.

لكن وراء الكواليس ، كانت الأمور تتغير. كان هناك لاعب جديد في المدينة واسمه nginx. يستخدمه كل من Automattic و WordPress.com منذ عام 2008. إنه خادم الويب الذي يدير أكبر نسبة من مواقع الويب عالية الحركة (التي يشغل الكثير منها WordPress). لهذا السبب تستخدمه الكثير من شركات الاستضافة المتطورة وكبار وكالات WordPress كخادم الويب الخاص بهم.

ليس الأمر أن Apache هو خادم ويب سيئ. هناك خبراء أباتشي يمكنهم جعله يعمل بشكل رائع في ظل كثرة حركة المرور. إنه لا يعمل بشكل جيد خارج الصندوق أو مع تكوين WordPress القياسي.

وفي الوقت نفسه ، فإن الغرض الوحيد من nginx هو التعامل مع عدد كبير من الزيارات. لهذا السبب بدأ Igor Sysoev المشروع عندما كان يعمل في Rambler.

أحد الأسباب التي تجعل nginx يتعامل مع المزيد من حركة المرور بشكل أفضل هو أنه يستخدم FastCGI للتواصل مع PHP. ما هو FastCGI؟ إنه بروتوكول يتيح تشغيل PHP كخدمة منفصلة عن خادم الويب.

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

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

HTTP / 2 هي ميزة خادم ويب مهمة أخرى يجب أن تعرفها. إنه الإصدار التالي من HTTP ، وهو البروتوكول الذي يدعم دورة الطلب والاستجابة بأكملها.

قبل وصول HTTP / 2 ، كان من الممكن أن يحتوي المتصفح على ستة اتصالات فقط بخادم الويب. ويمكن لكل اتصال معالجة طلب واحد فقط في كل مرة. لذلك ، في الممارسة العملية ، تم تحديد حد أقصى لدورة الطلب والاستجابة بستة طلبات في كل دورة.

هذه مشكلة حقيقية. تحتوي معظم مواقع الويب على عشرات الطلبات في دورتها. وجد المطورون ومسؤولو النظام طرقًا ذكية للالتفاف على هذا القيد.

أحد الحلول الأكثر شهرة هو ممارسة الجمع بين ملفات CSS و JavaScript. في سيناريو مثالي ، سيؤدي ذلك إلى خفض إجمالي عدد الطلبات لملفات CSS و JavaScript إلى اثنين: واحد لـ JavaScript والآخر لـ CSS.

هذا ليس ضروريًا مع HTTP / 2. يسمح HTTP / 2 بعدد غير محدود من الطلبات لكل اتصال. هذا يسمح لجميع الطلبات الإضافية بعد استجابة HTML الأولية أن تحدث في نفس الوقت.

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

ذاكرة التخزين المؤقت HTTP

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

حسنًا ، دعنا نعود إلى مثالنا السابق. يرسل المتصفح طلبًا للصفحة الرئيسية لـ modern.wordpress-stack.org ، ويتلقى خادم الويب هذا الطلب ويعيد توجيهه إلى PHP.

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

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

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

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

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

النكهات المختلفة لذاكرة التخزين المؤقت HTTP

في هذه المرحلة ، يجب أن تتساءل ، "كيف يمكنني الحصول على هذا الطفل على الخادم الخاص بي في أسرع وقت ممكن؟!" الخبر السار هو أن تثبيت ذاكرة التخزين المؤقت HTTP على خادم WordPress أمر سهل للغاية. إنه المكون الذي يحتوي على أكبر مجموعة من الخيارات.

قم بتثبيت مكون إضافي لـ Page-Caching

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

• باتكاشي
• هايبر كاش
• تمكين ذاكرة التخزين المؤقت
• صاروخ الفسفور الابيض
• WP Super Cache
• W3 إجمالي ذاكرة التخزين المؤقت

كل ما عدا WP Rocket متاح كمكونات إضافية مجانية في دليل WordPress. لذلك ، يمكنك تثبيت واحد واختباره على الفور. ومع ذلك ، من بين المكونات الإضافية الأربعة ، أفضلها هو WP Rocket. على الرغم من كونه مكونًا إضافيًا مدفوعًا ، إلا أنه يقوم بأكثر من مجرد إنشاء ذاكرة تخزين مؤقت لـ HTTP. تعمل هذه الفوائد الأخرى على تضخيم العمل الذي تقوم به ذاكرة التخزين المؤقت لـ HTTP.

كيف يعمل المكوِّن الإضافي للتخزين المؤقت للصفحة؟

تعمل كل هذه المكونات الإضافية على الاستفادة من ميزة Drop-in التي أتاحها WordPress للتخزين المؤقت. تتيح ميزة التخزين المؤقت الإضافية هذه للمكونات الإضافية إنشاء نظام ذاكرة تخزين مؤقت HTTP داخل WordPress. يحتاج التخزين المؤقت المؤقت إلى شيئين للعمل.

أولاً ، يجب أن يكون ملف الإسقاط advanced-cache.php في مجلد wp-content . هذا هو الملف الفعلي. ولكن على عكس معظم عمليات الانسحاب في WordPress ، لا يتم تشغيل هذا الخيار افتراضيًا. يحتاج WordPress أيضًا إلى أن يكون ثابت WP_CACHE true من أجل تحميل القائمة المنسدلة. في معظم الحالات ، يمكنك تعيين ذلك في wp-config.php .

يوضح الرسم البياني أعلاه ما يحدث عندما تقوم بتمكين القائمة المنسدلة باستخدام مكون إضافي للتخزين المؤقت. يُحمِّل WordPress الملف المنسدل في ملف wp-settings.php أثناء عملية التحميل. هذا مبكر بما فيه الكفاية في العملية بحيث لم يقم WordPress بأي شيء مضيعة للوقت حتى الآن.

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

الآن ، التخزين المؤقت للإخراج هو نظام مثير للاهتمام. ما يفعله هو التقاط كل المخرجات من نص PHP في متغير سلسلة حتى يحدث أحد أمرين:

• تخبر PHP بالتوقف عن التخزين المؤقت لإخراجها باستخدام إحدى الوظائف المضمنة ،
• ينتهي نص PHP ويحتاج إلى إرجاع استجابة إلى المتصفح.

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

اجعل خادم الويب يفعل ذلك

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

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

وإلا فسيتم إعادة توجيه الطلب إلى وحدة PHP (عادةً FastCGI). سيتم تمرير الطلب إلى WordPress حتى يتمكن من إنشاء استجابة. ستقوم وحدة ذاكرة التخزين المؤقت HTTP بعد ذلك بتخزين هذه الاستجابة مؤقتًا في طريق العودة.

يأتي كل من Apache و nginx مع القدرة على إضافة نظام ذاكرة التخزين المؤقت HTTP. إن nginx واحد مدمج. و Apache واحد هو وحدة منفصلة تحتاج لإضافتها إلى تثبيت Apache الخاص بك.

لا يوجد الكثير من المعلومات حول كيفية استخدام وحدة Apache مع PHP أو WordPress. قد يكون ذلك بسبب عدم شعبيته لدى حشد Apache ، أو ربما لأنه يحتوي على بعض المشكلات. هناك مشكلة واحدة على الأقل طويلة الأمد لا تزال مفتوحة.

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

أضف الورنيش إلى المكدس

ما هو الورنيش؟ إنه خادم ذاكرة تخزين مؤقت HTTP مخصص (أو ، كما يحب مطوروه تسميته ، مسرع HTTP). تستخدمه معظم مواقع الويب عالية الحركة وشركات الاستضافة المتميزة كحل لذاكرة التخزين المؤقت لـ HTTP.

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

هذه هي الاختلافات الرئيسية بين استخدامه ومجرد استخدام ذاكرة التخزين المؤقت لخادم الويب المدمج في HTTP. تعد ذاكرة التخزين المؤقت لخادم الويب HTTP عالية الأداء ولكنها أساسية أيضًا. ليس لديك الكثير من التحكم بخلاف بعض خيارات التكوين.

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

يوضح الرسم البياني أعلاه هذا التعقيد الإضافي. لدينا الآن مكونان آخران في مكدس خادم WordPress الخاص بنا: الورنيش والوكيل العكسي.

يوجد وكيل عكسي للتغلب على القيود التي يفرضها Varnish مع SSL. يجلس أمام Varnish ويفك تشفير الطلبات التي يتلقاها خادمنا. يمكنك أيضًا استدعاء هذا النوع من الوكيل العكسي بروكسي إنهاء SSL. يقوم الوكيل بعد ذلك بإرسال هذه الطلبات التي تم فك تشفيرها إلى Varnish لمعالجتها.

بمجرد وصول الطلب إلى Varnish ، يبدأ ملف (ملفات) تكوين VCL. إنهم عقل Varnish. على سبيل المثال ، يقولون له كيف:

• تحليل وتنظيف وتعديل الطلبات الواردة ؛
• ابحث عن استجابة مخبأة ؛
• تحليل وتنظيف وتعديل الردود المرتجعة من WordPress ؛
• تخزين هذه الردود المرتجعة مؤقتًا ؛
• معالجة طلب لإزالة رد واحد أو أكثر من ذاكرة التخزين المؤقت.

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

ووردبريس

حسنًا ، طلبنا للصفحة الرئيسية لـ modern.wordpress-stack.org قد وصل إلى WordPress. لقد مرت بدورة الطلب والرد التي غطيناها للتو. فعلت ذاكرة التخزين المؤقت HTTP كل ما في وسعها للعثور على استجابة HTTP لإرسالها مرة أخرى.

ولكن لم تكن هناك استجابة HTTP مخبأة لإرسالها مرة أخرى إلى المتصفح. في تلك المرحلة ، لم يكن لذاكرة التخزين المؤقت لـ HTTP خيار آخر. كان عليه إعادة توجيه طلب HTTP إلى WordPress.

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

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

العقبة الأخرى هي استعلامات قاعدة البيانات التي يحتاج WordPress إلى تنفيذها. استعلامات قاعدة البيانات هي عمليات مكلفة. كلما زاد عددها ، كلما كان WordPress أبطأ. سيكون هذا هو محور تركيز القسم الأخير في دورة الاستعلام والنتيجة.

تحسين وقت تشغيل PHP

دعنا نعود إلى PHP. في هذه اللحظة ، يشترط WordPress الحد الأدنى من متطلبات PHP 5.2. هذا الإصدار من PHP عمره 10 سنوات تقريبًا! (توقف فريق PHP عن دعمها في عام 2011.)

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

استخدم أحدث إصدار من PHP

أسهل شيء يمكنك القيام به هو ترقية إصدار PHP الخاص بك. شهدت الإصدارات 5.4 و 5.5 و 5.6 تحسينات في الأداء. كان التحسن الأكبر من 5.3 إلى 5.4. أدى التحول إليه إلى زيادة أداء WordPress بمقدار مناسب.

قم بتثبيت التخزين المؤقت لرمز التشغيل

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

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

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

قم بالتبديل إلى مترجم من الجيل التالي

آخر شيء يمكنك القيام به هو التبديل إلى أحد مجمعي الجيل التالي: إما HHVM من Facebook أو PHP 7 ، أحدث إصدار من PHP. (لماذا PHP 7؟ إنها قصة طويلة.)

قام Facebook وفريق PHP ببناء هذين المجمعين من الألف إلى الياء. لقد أرادوا الاستفادة من استراتيجيات التجميع الأكثر حداثة. يستخدم HHVM التجميع في الوقت المناسب ، بينما يستخدم PHP 7 التجميع المسبق. كلاهما يقدم تحسينات لا تصدق في الأداء مقارنة بـ PHP 5 الجيد.

كان HHVM أول من وصل إلى الساحة منذ بضع سنوات. حقق الكثير من مضيفي المستوى الأعلى نجاحًا كبيرًا في ذلك ، حيث قدموه كمترجم PHP أساسي لهم.

ومع ذلك ، يجدر التأكيد على أن HHVM ليس مترجم PHP رسمي. إنه غير متوافق مع PHP بنسبة 100٪. السبب هو أن HHVM ليس مصممًا فقط لدعم PHP ؛ إنه أيضًا مترجم للغة برمجة Hack على Facebook.

PHP 7 هو مترجم PHP رسمي. لم يكن موجودًا منذ فترة طويلة. أصدره فريق PHP في ديسمبر 2015. هذا لم يمنع بعض شركات استضافة WordPress من دعمه بالفعل.

الخبر السار هو أن WordPress نفسه متوافق بنسبة 100٪ مع كلا المجمعين! الأخبار السيئة هي أنه ليست كل المكونات الإضافية والسمات كذلك ، لأن الحد الأدنى لإصدار PHP لـ WordPress لا يزال 5.2.

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

دورة نتيجة الاستعلام

في هذه المرحلة ، يمر وقت تشغيل PHP عبر جميع ملفات WordPress PHP وتنفيذها. ومع ذلك ، لا تحتوي ملفات WordPress PHP هذه على أي بيانات. أنها تحتوي فقط على كود WordPress.

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

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

تحسين دورة نتائج الاستعلام

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

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

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

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

عناصر المكدس لدورة الاستعلام والنتيجة

لنلقِ نظرة على عناصر المكدس المختلفة المتضمنة في دورة نتيجة الاستعلام. هذا الجزء من المكدس أقل تعقيدًا. لكنه لا يزال يتضمن أكثر من مكون - أي خادم قاعدة بيانات MySQL وذاكرة التخزين المؤقت للكائن.

خادم قاعدة بيانات MySQL

قبل بضع سنوات ، كان خادم قاعدة بيانات MySQL يعني نفس الشيء للجميع. كان خادمًا مثبتًا عليه خادم MySQL. لكن الأمور تغيرت كثيرًا في السنوات الأخيرة.

لم تكن المجموعات المختلفة راضية عن الطريقة التي تدير بها Oracle مشروع MySQL. لذلك ، قامت كل مجموعة بتشكيلها وإنشاء نسختها الخاصة التي يمكنك "إسقاطها" بدلاً من ذلك. والنتيجة هي أن هناك الآن العديد من خوادم قاعدة بيانات MySQL.

خادم MySQL "الرسمي" الجديد هو خادم MariaDB. إنها النسخة المطورة من قبل المجتمع لخادم MySQL. يخطط المجتمع للحفاظ على التوافق الكامل مع مشروع خادم MySQL.

بديل شائع آخر لـ MySQL هو خادم Percona. على عكس MariaDB ، فإن Percona هي فرع من MySQL. مطوروها ليسوا ضد مشروع MySQL نفسه ؛ يريدون فقط التركيز على تحسين أداء MySQL. قام فريق MariaDB لاحقًا بدمج بعض تحسينات الأداء هذه في مشروع MariaDB.

في نهاية اليوم ، يمكنك اختيار الشخص الذي تفضله. لا يوجد فرق في الأداء بين خادم Percona وخادم MariaDB (بالنسبة لمعظمنا على أي حال). كلاهما يعمل بشكل أفضل من MySQL. ومع ذلك ، تحافظ بيركونا على توافق أوثق مع مشروع أوراكل.

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

يحتوي خادم قاعدة البيانات على العديد من محركات التخزين. لن ننظر إليهم جميعًا. اثنان فقط من اهتمامنا: InnoDB و MyISAM.

بشكل افتراضي ، يستخدم WordPress محرك قاعدة بيانات MySQL الافتراضي. قبل MySQL 5.5 ، كان هذا المحرك هو MyISAM. إذا كنت تدير موقع ويب WordPress صغيرًا ، فإن MyISAM جيد. يواجه MyISAM مشكلات في الأداء بمجرد نمو حجم موقع الويب. في هذه المرحلة ، يعد InnoDB هو الخيار الوحيد لمحرك قاعدة بيانات.

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

MySQLTuner هو برنامج نصي صغير يقوم بتحليل خادم قاعدة البيانات الخاص بك. سيُنشئ تقريرًا ويعطيك توصيات ضبط.

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

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

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

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

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

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

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

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

غالبًا ما تأتي ذاكرة التخزين المؤقت للكائنات الدائمة في شكل مكون إضافي. سيستفيد هذا المكون الإضافي من القائمة المنسدلة object-cache.php وظيفته. تتيح هذه القائمة المنسدلة لمؤلفي المكون الإضافي تغيير السلوك الافتراضي لذاكرة التخزين المؤقت للكائن.

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

ملحقات ذاكرة التخزين المؤقت للكائنات الثابتة

في الوقت الحاضر ، هناك خياران شائعان لمخزن البيانات للتخزين المؤقت للكائن الدائم:

• Memcached (ملحق)
• Redis (البرنامج المساعد)

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

المشكلة الوحيدة هي أنها لا تأتي مثبتة مسبقًا على الخوادم. وكذلك امتداد PHP الخاص بهم (وهو اختياري مع Redis). تحتاج إلى تثبيت واحد قبل أن تتمكن من استخدام المكوّن الإضافي WordPress المقابل.

أي واحد يجب عليك تثبيته؟ من الناحية العملية ، لا يوجد فرق كبير بين الاثنين للتخزين المؤقت للكائن. في الماضي ، كان الخيار الشائع هو Memcached. لقد تغير هذا خلال السنوات القليلة الماضية. أضاف Redis الكثير من الميزات التي جعلت منه خيار الانتقال للتخزين المؤقت للكائن.

الحصول على خادم WordPress الحديث الخاص بك

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

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

DebOps لـ WordPress

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

يقوم DebOps for WordPress بتهيئة الخادم بما يلي:

• HHVM (حتى يتم تحويل PHP 7 إلى مستودع Linux رسمي)
• MariaDB
• nginx
• ريديس
• الورنيش

تقوم الأداة بأكثر من مجرد تكوين خادم بأحدث التقنيات. كما أنه يعتني بتأمين الخادم نيابة عنك. هذا شيء غالبًا ما يغفله الناس عند إدارة خادمهم.

EasyEngine

EasyEngine هي أداة سطر أوامر مصممة لمساعدتك في إعداد موقع WordPress على الخادم. إن الشيء العظيم في EasyEngine هو مرونته: يمكنك استخدامه لإعداد أي مجموعة تقريبًا من تقنيات الخادم التي نظرنا إليها حتى الآن.

على سبيل المثال ، يتيح لك إعداد خادم إما باستخدام HHVM أو PHP 7. ويتيح لك الاختيار بين Memcached و Redis لتخزين البيانات الثابتة. ويتيح لك تثبيت أدوات المسؤول مثل phpMyAdmin.

كما أنه يوفر عددًا كبيرًا من الخيارات عند إنشاء موقع ويب WordPress. يمكنك إخباره بإعداد موقع ويب باستخدام ذاكرة تخزين مؤقت HTTP باستخدام مكون إضافي أو nginx. كل هذه المرونة هي سبب كون EasyEngine أداة شائعة.

تعريشة

Trellis هي أداة تم تطويرها بواسطة Roots. مثل DebOps ، يقوم بتهيئة الخادم بمجموعة محددة من تقنيات الخادم:

• MariaDB
• ميمكاشد
• nginx
• مخبأ nginx HTTP (اختياري)
• PHP 7

شيء واحد يجب معرفته عن Trellis هو علاقته بـ Bedrock ، وهي أداة أخرى أنشأتها Roots. Bedrock هو نموذج معياري لهيكلة موقع WordPress حول مبادئ "Twelve-Factor App".

أنشأ فريق Roots Trellis لتمكين الأشخاص من تكوين خادم يستخدم موقع (مواقع) WordPress المُنظَّمة من Bedrock. لا يمكنك استخدامه مع تثبيت WordPress عادي ، لذا ضع ذلك في الاعتبار.

لقد تغير الزمن

كما ترى ، يحتوي خادم WordPress على الكثير من الأجزاء المتحركة اليوم! لكن هذا لا يجب أن يكون سببًا لليأس. إنه ليس سيئًا كما يبدو لأنك لست بحاجة دائمًا إلى استخدام جميع الأجزاء.

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