هذه المقالة هي بالأحرى من سلسلة "ملاحظات مضيفة". حسنًا ، المزيد عن التجارب الشخصية والتلاعب.
إذا كان عليك التعامل مع مواقع WordPress التي تم تثبيت المكون الإضافي للتخزين المؤقت WP Super Cache فيها ، فقد تكون المقالة مفيدة لك. خلاف ذلك ، هذه مجرد قصة قصيرة.
باختصار ، بداية القصة هي: كان هناك موقع. الأخبار والمعلومات المواضيعية. مصنوعة من قبل معالج غير معروف على CMS WordPress. ويتم ذلك بالضبط كما كان مسموحًا به في تلك اللحظة عن طريق صاحبه. مع مرور الوقت ، اكتسب الموقع شعبية ، وازداد عدد الزوار. الموقع نفسه "حصل" على الإعلانات. على سبيل المثال كلما زاد عدد الزوار ، كان ذلك أفضل. في مرحلة ما ، أثناء ذروة الأحمال ، بدأ الموقع في التقديم: تم تحميل الصفحات ببطء وكل ذلك. ولكن ، بالطبع ، حتى تنقر الديك ، لم يتحرك أحد حقًا. ظهر الديك في الوقت الذي كان من المفترض أن يغطي الموقع بعض الأحداث التي جذبت انتباه الجمهور. ركض الزوار ، وانخفض الموقع ، وكانت جميع الإيرادات المقدرة تذوب أمام أعيننا. بسبب الظروف ، كان علي أن أكون بمثابة إنعاش. لقد كتبت
مقالًا حول هذا الوقت. كان قراري مخيفًا (لا تكرر) ، ولكن تم تحقيق الهدف الرئيسي - تم حفظ الأحلام. في الغالب.
بالطبع ، لم يكن أحد مهتمًا بتكرار موقف مماثل وعمل على الموقع. بادئ ذي بدء ، اكتشفوا أسباب السقوط والحمل المرتفع على الخادم. كانت شائعة: عدم وجود موقع للتخزين المؤقت في حد ذاته وآلية تنفيذ سيئة لتسجيل وعرض عدد مشاهدات المقالة. قام هذا الأخير نفسه بإنشاء حمل لائق: مع كل طلب لصفحة المقالة ، أخذ من مشاهدات قاعدة البيانات عدد مشاهدات هذه المقالة ، وعرضها ، ثم أضاف واحدة وأعادها إلى قاعدة البيانات. في الوقت نفسه ، تم استخدام جدول
wp_postmeta مع البيانات الوصفية للتخزين (كما يبدو أنه يسمى في WP). حيث تم تخزين الكتلة غير ذات صلة تمامًا بالآراء المحاسبية للمعلومات والتي كانت كبيرة جدًا.
تم حل مشكلة التخزين المؤقت ببساطة: في بيئة هادئة ، تم تثبيت البرنامج المساعد WP Super Cache بشكل طبيعي. ما ، نصحني الكثير ، إذا تذكرت بشكل صحيح ، أن أفعل بدلاً من العكاز الغريب الذي بنته في التعليقات على مقالتي تلك. بصراحة ، كنت أتنقل بين الحين والآخر بشكل سيئ في نظام WordPress البيئي ، وبالتالي ظهر هذا العكاز. تم تثبيت المكون الإضافي للتخزين المؤقت وتهيئته من خلال معرفة الأشخاص بالفعل ، وتم تشغيله بمجرد إخراجه من العلبة. وبالتالي ، تم حل مشكلة التخزين المؤقت. لماذا تم اختيار هذا المكون الإضافي ، لا أعرف بالتأكيد. بقدر ما أفهم ، هذا هو أحد المكونات الإضافية الأكثر شيوعًا من هذا النوع لـ WP.
بالنظر إلى الآراء ، تصرفوا بشكل مختلف إلى حد ما. من الواضح أنه كان يجب التخلي عن الآلية الأصلية. لم أكن أرفض أن آخذ في الاعتبار الآراء نفسها: على الأقل تم حظر كتلة تظهر مثل "المقالات الأكثر شعبية في الأسبوع". جميع المكونات الإضافية لتسجيل المشاهدات ، حتى لو كانوا "أصدقاء" مع البرنامج المساعد للتخزين المؤقت ، تبين أنها شديدة الشراسة ، وفي معظم الأحيان ، نفذت نفس الآلية مع كتابة واستخراج البيانات من wp_postmeta. بالنسبة للموقع الصغير ، هذا مناسب تمامًا. بالنسبة لموقع يتمتع بمعدلات حضور ذروة صلبة إلى حد ما - لم يعد: الشراهة الزائدة لهذه الوظيفة الصغيرة. ثم ، بالمناسبة ، ظهرت استضافة مدفوعة الأجر وغير مستخدمة لسنوات قادمة. أسهل وأرخص. تم تكديس مسؤوليات تخزين وتسجيل وإعادة البيانات حول المشاهدات عليه. كل شيء غير متزامن ، أي حتى في حالة سقوطه ، سيستمر الموقع الرئيسي في عرض المقالات والإعلانات وكل شيء يجب أن يعرضه بهدوء. تم تخصيص التخزين عبر الإنترنت لعرض البيانات إلى Redis ، والتخزين طويل الأجل إلى MySQL. لذلك فهي تدور ، ولا تسأل حقًا ، وتتناول 1-2 ٪ من الحد الأقصى للحمل المسموح به على تلك الاستضافة.
وهكذا ، يمر وقت طويل. مرة أخرى ليلة ومرة أخرى قصة قديمة. تذهب حركة المرور القوية إلى الموقع ويبدأ الموقع في الانخفاض. ومرة أخرى ، أنا الاختصاصي الشرطي الوحيد في المنطقة. بالطبع أنا مندهش من تكرار الأحداث. فكرتي الأولى هي أن شخصًا ما أوقف التخزين المؤقت عن طريق الخطأ. ولكن لا ، في التعليمات البرمجية المصدر لصفحة الموقع التي يمنحني إياها الخادم المتساقط ، أرى علامات على عمل مكون إضافي للتخزين المؤقت. يجب أن يكون كل شيء على ما يرام. ولكن في لوحة تحكم الخادم ، أرى أنه لم يعد هناك ذاكرة وصول عشوائي متبقية ، وعدد استعلامات قاعدة البيانات أمر لا يصدق وكل شيء سيء. بادئ ذي بدء ، أفتح الصفحة مع وصف المكون الإضافي ، وأجري بسرعة من خلال عينيها ، ولا أجد شيئًا وأترك هذا النشاط. الخطوة التالية هي رؤية الإحصائيات. أرى أن تدفق حركة المرور الرئيسي يتدفق إلى الموقع من Yandex.Zen. والطلب الذي يقود المستخدم إلى الموقع يبدو كما يلي:
https://example.com ؟ utm_referrer = https:٪ 2F٪ 2Fzen.yandex.com
على سبيل المثال يضيف Yandex.Zen علامة utm الخاصة به إلى العنوان. نظرًا لأن الخادم يستلقي تمامًا ولا يعطيني 500 فقط ، لسبب ما لا يمكنني التحقق بوضوح من النظرية القائلة بأن الصفحات التي تحتوي على هذا "الترجيح" لا يتم تخزينها مؤقتًا. لذلك ، ولدت "عكاز" آخر (تم استبداله لاحقًا): تمت إضافة إعادة توجيه إلى htaccess ، والذي يحول الطلب باستخدام علامات utm إلى طلب بدونها قبل أن يبدأ WordPress وجميع المكونات الإضافية القوية في اللعب. الجهاز يعيد التشغيل ، وفويلا يعمل كل شيء: يتم تحميل الموقع بسرعة ، ويسرق الخادم بهدوء بسرعات منخفضة. كما لم يحدث شيء.
ثم استرخيت وتسلقت بهدوء أشاهد إعدادات البرنامج المساعد للتخزين المؤقت. بادئ ذي بدء ، خانة الاختيار "لا تقم بتخزين الصفحات مع معلمات GET" ، الموجودة هناك. كل شيء على ما يرام ، إنها لا تستحق ذلك. بالإضافة إلى ذلك ، كما أظهرت التجربة ، يتعامل البرنامج المساعد مع التخزين المؤقت للاستعلام مع أي مجموعة من المعلمات العشوائية. إذا لم تكن هذه علامات utm (في الواقع ، فقد أعدت توجيه الطلبات من نوع معين فقط ولم أقطع جميع علامات utm).
هنا نظرت بعناية (باستخدام CTRL + F) في صفحة البرنامج المساعد. ووجدت في الأسئلة الشائعة الفقرة الرائعة "كيف يمكنني استخدام أدوات تتبع utm_source في Google Analytics مع هذا المكون الإضافي؟". من الواضح أنني تجاهلته بأمان أثناء الفحص السريع: لا يبدو أن هناك أي علاقة بالمشكلة. في الوقت نفسه ، بالمناسبة ، إنها ليست غنية بالمعلومات ولا تقدم أي حل محدد.
الاستنتاج المفيد الوحيد الممكن في المقالة: إذا كان لديك موقع WP مزودًا بالمكون الإضافي WP Super Cache ، فتحقق مما يفعله (أو لا يفعله) ، إذا قمت بتقديم طلب بالمعلمات "؟ Utm_referrer = https:٪ 2F٪ 2Fzen. yandex.com "، إلخ. لست متأكدًا من أنه عند تثبيت هذا المكون الإضافي ، يقرأ الجميع الأسئلة الشائعة بعناية. يبدو أن التطبيق المحدد يبقى على عاتق مالكي الموقع: عندما نظرت آخر مرة في تحديث هذا المكون الإضافي ، لم أر أي تغييرات فيما يتعلق برد فعله الغريب على علامات utm.
لكن القصة كانت ستكون غير مكتملة (وما كنت لأخبرها) لو لم يكن هناك تأكيد آخر لقانون مورفي. بينما تواصلنا بسلام مع صاحب الموقع وشاهدنا كيف يعمل الموقع بهدوء لمدة ساعة تقريبًا ... سقط الموقع. بشكل غير متوقع وأخيرًا. لا يوجد وصول إلى لوحة تحكم الخادم ، FTP ، SSH وكل شيء آخر لا يعمل. لا شيء يعمل. إذا كان ضغطي قبل ذلك قد تم رفعه قليلاً عن طريق حل المشكلة التي أثارها ج. والشعور الغامض الوحيد بأن خطين في htaccess لا يمكن أن يقتلوا كل شيء بعد ساعة من صنع هذه الخطوط لم يسمح لـ "mini" بالتحول إلى شيء أكثر اكتمالاً. بشكل عام ، بعد دقيقتين من تبادل الرسائل المفاجئة ، صعدنا إلى الحساب الشخصي لموفر الاستضافة حيث يعيش الخادم. وهناك ، في التذاكر ، وجدنا تحذيرًا حول "العمل الفني من X إلى Y على MSC." الشيء الأكثر إثارة للاهتمام هو أنه في مكتب البريد ، بغض النظر عن كيفية البحث ، لم نجد أي رسائل من المضيف حول هذه الأعمال. كان عمر التذكرة يوم واحد على الأقل. قبل ذلك ، وصلت هذه الرسائل إلى البريد ، ولا أحد عادة ينظر إلى تذاكر خدمة الدعم (ومكتب المضيف نفسه) عادة دون أي حاجة خاصة. لذلك ، كان ما حدث مفاجأة كبيرة. بعد ذلك ، وبخنا أعين المضيف ، وضحكنا ، وانتظرنا حتى نجح كل شيء ونام.
هنا قصة.