कैसे Yandex.Zen, वर्डप्रेस कैशिंग प्लगिन और होस्टिंग ने मेरा दबाव बढ़ाया

यह लेख, बल्कि, "परिचारिका नोट्स" की एक श्रृंखला से है। खैर, व्यक्तिगत अनुभवों और गुगिंग के बारे में थोड़ा और।

यदि आपको वर्डप्रेस साइटों से निपटना है जिसमें WP सुपर कैश कैशिंग प्लगइन स्थापित है, तो लेख आपके लिए उपयोगी हो सकता है। अन्यथा, यह सिर्फ एक छोटी कहानी है।

संक्षेप में, कहानी की शुरुआत यह है: एक साइट थी। विषयगत समाचार और जानकारी। सीएमएस वर्डप्रेस पर एक अज्ञात जादूगर द्वारा बनाया गया। और ठीक वैसा ही किया जैसा कि उस समय उसके मालिक के माध्यम से अनुमति दी गई थी। समय के साथ, साइट ने लोकप्रियता हासिल की, आगंतुकों की संख्या में वृद्धि हुई। विज्ञापन पर साइट "अर्जित" है। यानी अधिक आगंतुकों, बेहतर है। कुछ बिंदु पर, पीक लोड्स के दौरान, साइट चालू होना शुरू हुई: पृष्ठों को धीरे-धीरे लोड किया गया और वह सब। लेकिन, ज़ाहिर है, जब तक मुर्गा pecked, कोई भी वास्तव में चले गए। रोस्टर उस समय दिखाई दिया जब साइट को किसी घटना को कवर करना था, जिसने जनता का ध्यान आकर्षित किया। आगंतुक भाग गए, साइट नीचे चली गई, और सभी अनुमानित राजस्व हमारी आंखों के सामने पिघल रहे थे। परिस्थितियों के कारण, मुझे पुनर्जीवन के रूप में कार्य करना पड़ा। मैंने तब इस बारे में एक लेख लिखा था। मेरा निर्णय डरावना था (दोहराएं नहीं), लेकिन मुख्य लक्ष्य पूरा हो गया था - सपने बच गए थे। मूल रूप से।

बेशक, कोई भी एक समान स्थिति को दोहराने में दिलचस्पी नहीं रखता था और साइट पर काम करता था। सबसे पहले, उन्होंने सर्वर पर गिरावट और उच्च भार के कारणों का पता लगाया। वे आम थे: इस तरह के रूप में एक कैशिंग साइट की कमी और रिकॉर्डिंग विचारों की संख्या को प्रदर्शित करने और प्रदर्शित करने के लिए एक खराब कार्यान्वित तंत्र। उत्तरार्द्ध ने खुद एक अच्छा भार बनाया: लेख के पृष्ठ के प्रत्येक अनुरोध के साथ, उन्होंने डेटाबेस से इस लेख के विचारों की संख्या ली, इसे प्रदर्शित किया, और फिर एक को जोड़ा और इसे डेटाबेस में वापस लिखा। उसी समय, मेटाडेटा के साथ wp_postmeta तालिका का उपयोग भंडारण के लिए किया गया था (जैसा कि WP में कहा जाता है)। जिसमें जन सूचना के लेखा विचारों के लिए पूरी तरह अप्रासंगिक हो गया था और जो बहुत बड़ा था।

कैशिंग समस्या को बस हल किया गया था: एक शांत वातावरण में, WP सुपर कैश प्लगइन सामान्य रूप से स्थापित किया गया था। क्या, कई, अगर मुझे सही याद है, तो मुझे उस भयानक बैसाखी के बजाय करने की सलाह दी, जो मैंने उस लेख पर टिप्पणी में बनाया था। ईमानदारी से, मैं तब और अब 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 टैग के साथ अनुरोध को परिवर्तित करता है और इसके सभी शक्तिशाली प्लगइन्स खेलने में आते हैं। मशीन रिबूट और, वॉयला, सब कुछ काम करता है: साइट जल्दी से लोड होती है, सर्वर कम गति पर चुपचाप सरसराहट करता है। जैसे कुछ हुआ ही नहीं।

फिर मैंने आराम किया और कैशिंग प्लगइन की सेटिंग्स को देखकर शांति से चढ़ गया। सबसे पहले, चेकबॉक्स "जीईटी मापदंडों के साथ पृष्ठों को कैश न करें", जो वहां है। सब कुछ ठीक है, वह इसके लायक नहीं है। इसके अलावा, जैसा कि प्रयोग दिखाया गया है, प्लगइन क्वेरी कैशिंग के साथ मनमाने मापदंडों के किसी भी सेट के साथ मुकाबला करता है। यदि ये यूटीएम टैग नहीं हैं (वास्तव में, मैं केवल एक निश्चित प्रकार के अनुरोधों को पुनर्निर्देशित करता हूं और सभी यूटीएम टैग नहीं काटता)।

यहाँ मैंने सावधानी से (CTRL + F का उपयोग करके) प्लगइन पेज को देखा। और मुझे वहाँ पूछे जाने वाले प्रश्न में शानदार पैराग्राफ "मुझे इस प्लगइन के साथ Google में utm_source ट्रैकिंग टूल का सर्वोत्तम उपयोग कैसे करना चाहिए?"। यह स्पष्ट है कि पहली सरसरी परीक्षा के दौरान, मैंने उसे सुरक्षित रूप से अनदेखा कर दिया: लगता है कि समस्या से कोई लेना-देना नहीं है। उसी समय, वैसे, यह बहुत जानकारीपूर्ण नहीं है और किसी भी विशिष्ट समाधान की पेशकश नहीं करता है।

लेख में एकमात्र संभव उपयोगी निष्कर्ष: यदि आपके पास WP सुपर कैश प्लगइन के साथ एक WP साइट है, तो यह जांचें कि यह क्या करता है (या नहीं करता है), यदि आप मापदंडों के साथ एक अनुरोध सबमिट करते हैं? "Utm_referrer = https:% 2%% 2Fzen। yandex.com ", आदि। मुझे यकीन नहीं है कि इस प्लगइन को स्थापित करते समय, हर कोई इसके FAQ को इतनी सावधानी से पढ़ता है। विशिष्ट कार्यान्वयन, जाहिरा तौर पर, साइट मालिकों के साथ रहता है: जब मैंने आखिरी बार इस प्लगइन के अपडेट को देखा था, तो मैंने यूटीएम टैग्स के लिए इसकी अजीब प्रतिक्रिया के बारे में कोई बदलाव नहीं देखा था।

लेकिन कहानी अधूरी होती (और मैंने यह नहीं बताया होता) यदि मर्फी के कानून की एक और पुष्टि नहीं हुई होती। जबकि हमने साइट के मालिक के साथ शांति से पत्र व्यवहार किया और देखा कि साइट ने लगभग एक घंटे तक चुपचाप कैसे काम किया ... साइट गिर गई। अप्रत्याशित रूप से और अंत में। सर्वर कंट्रोल पैनल, एफ़टीपी, एसएसएच तक पहुंच नहीं है और बाकी सब कुछ काम नहीं करता है। कुछ भी काम नहीं करता। अगर इससे पहले कि जे। ज़ेन और कैशिंग प्लगइन ने समस्या को हल करके मेरा दबाव थोड़ा बढ़ा दिया था (आखिरकार, एक आसान परेशानी में किसी चीज़ को जल्दी से समझने और ठीक करने के लिए एक विशेष खुशी है), तो मेरे लिए एक पूरे मिनी-आतंक हमला हुआ। और केवल अस्पष्ट लग रहा है कि इन पंक्तियों को बनाने के एक घंटे बाद .htaccess में सब कुछ नहीं मार सकता है, "पंक्तियों" को "मिनी" को कुछ और पूरा होने नहीं दिया। सामान्य तौर पर, आश्चर्यचकित संदेशों का आदान-प्रदान करने के कुछ मिनटों के बाद, हम होस्टिंग प्रदाता के व्यक्तिगत खाते में चढ़ गए जहां सर्वर रहता है। और वहां, टिकटों में, हमने "एमएससी पर एक्स से वाई तक तकनीकी कार्य" के बारे में चेतावनी दी। सबसे दिलचस्प बात यह है कि पोस्ट ऑफिस में, चाहे हमने कोई भी खोज की हो, हमें इन कार्यों के बारे में होस्टर से कोई संदेश नहीं मिला। टिकट कम से कम एक दिन पुराना था। इससे पहले, इस तरह के संदेश मेल में आए थे, और कोई भी आमतौर पर बिना किसी विशेष आवश्यकता के समर्थन सेवा (और खुद के होस्टल कार्यालय) के टिकटों को देखता है। इसलिए, जो हुआ वह एक बड़ा आश्चर्य था। उसके बाद, हमने होस्टर की आँखों को डाँटा, हँसे, इंतजार किया जब तक कि सब कुछ काम नहीं किया और सो गया।

यहाँ एक कहानी है।