👩🏻 👩🏾‍💼 👨🏻 मिलियन वर्डप्रेस विज़िटर बनाम सर्वर 🙋🏿 👩🏾‍🌾 👨‍🎤

मेरा सर्वर, जो बाद की कहानी का नायक होगा, एक नियमित मध्यवर्गीय सर्वर है जो फर्स्टकैड से एक ड्यूलकोर एक्सोन E3110 3.00Ghz प्रोसेसर के साथ किराए पर लिया गया है। रैम 4 जीबी स्थापित किया गया था, 500 जीबी की हार्ड ड्राइव। सर्वर पर, nginx 1.01 को फ्रंटेंड के रूप में स्थापित किया गया था, और अपाचे 2 को बैकेंड के रूप में, CGI मोड में चलने वाली स्क्रिप्ट के साथ स्थापित किया गया था।

कहानी एक ऐसी साइट के साथ हुई जो मेरे सर्वर पर पोस्ट की गई थी, वास्तव में, साइट नहीं, बल्कि किसी और का निजी ब्लॉग । इससे पहले ब्लॉग पर, प्रति दिन 10,000 तक की यातायात चोटियों का अवलोकन किया गया था, लेकिन सर्वर ने इस लोड के साथ मानक कॉन्फ़िगरेशन फ़ाइलों पर किसी भी अनुकूलन के बिना धमाके के साथ मुकाबला किया।

और इसलिए, एक ठीक "महिला दिवस", सुबह में, साइट की निगरानी सेवा से एक एसएमएस आता है कि सर्वर अनुपलब्ध है। स्वाभाविक रूप से, मैं तुरंत ऐसी खबरों से जागता हूं और सर्वर को पिंग करने की कोशिश करता हूं। पिंग मौजूद था, लेकिन बहुत सुस्त। एक SSH कनेक्शन स्थापित नहीं किया जा सकता है क्योंकि सभी सर्वर संसाधन किसी अज्ञात प्रक्रिया, या प्रक्रियाओं को दिए जाते हैं।

केवीएम के माध्यम से कनेक्ट करते हुए, मैंने सर्वर को रिबूट करने के लिए भेजा, और एसएसएच के माध्यम से कनेक्ट होने के तुरंत बाद बूट किया। प्रक्रियाओं में, मैंने एक भयानक तस्वीर देखी: ब्लॉग के लेखक की ओर से लगभग 1000 php प्रक्रियाएं शुरू की गईं, इसके अलावा, लोड औसत एक सौ से अधिक हैं। एक बहुत ही डरावना सूचक जो दिखाता है कि संसाधनों के एक हिस्से के लिए प्रक्रिया को अपनी बारी में कितनी उम्मीद करनी है।

स्वाभाविक रूप से, मेरे पास शीर्ष कमांड चलाकर इसे देखने का पर्याप्त समय था। एक मिनट के भीतर, सर्वर ने प्रतिक्रिया देना बंद कर दिया, और मुझे इसे फिर से चालू करना पड़ा, और रिबूट करने के तुरंत बाद, अपाचे को बंद कर दें। अब मुझे एक सर्वर प्राप्त करने की गारंटी है जो सभी संसाधनों का उपभोग नहीं करता है। मैंने विश्लेषण शुरू किया, मैंने नेटस्टैट कमांड के साथ खुले कनेक्शनों की संख्या घटा दी और भयभीत हो गया। नंगेक्स के साथ 10,000 से अधिक स्थापित कनेक्शन थे। इसका मतलब है कि अंतिम मिनट में ग्राहक की साइट पर प्रवेश करने के लिए 10 हजार प्रयास हुए - एक अच्छा भार।

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

सभी संभावित प्लगइन्स को बंद करने और कम से कम अनुरोधों के साथ विषय को फिर से लिखना, लोड कम नहीं हुआ। मुझे अत्यधिक उपायों के लिए जाना पड़ा - मैंने नगनेक्स में अनुमानित अनुरोधों की मजबूर कैशिंग को चालू कर दिया। ऐसा करने के लिए, मैंने http अनुभाग में निम्नलिखित पंक्ति दर्ज की

proxy_cache_path /path/to/cache levels=1:2 keys_zone=wpblog:10m max_size=10m;

हमें जो सर्वर सेक्शन चाहिए, उसमें हम लिखते हैं:

 proxy_cache_valid 200 3m; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080;

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

 proxy_cache_valid 200 3m; location / { if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) { set $do_not_cache 1; } proxy_no_cache $do_not_cache; proxy_cache_bypass $do_not_cache; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080; } location ~* wp\-.*\.php|wp\-admin { proxy_pass http://127.0.0.1:8080; } location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ { root /path/to/static; access_log off; expires max; add_header Last-Modified: $date_gmt; } location ~* \/[^\/]+\/(feed|\.xml)\/? { proxy_pass http://127.0.0.1:8080; }

इसके बाद, काम में असुविधाओं को निरंतरता द्वारा पूरी तरह से मुआवजा दिया जाता है।

उपरोक्त सभी के परिणामस्वरूप, सर्वर 2 घंटे के लिए अनुपलब्ध था, इस समय के दौरान ट्रैफ़िक का प्रवाह काफी कम हो गया था, लेकिन इस घटना के बाद अन्य समान अवकाश ट्रैफ़िक स्पाइक्स थे जो सर्वर पर ध्यान देने योग्य भार दिए बिना साइट को सफलतापूर्वक हटा दिया। तब से, मैं सभी होस्ट किए गए वर्डप्रेस साइटों पर इस तरह के कॉन्फ़िगरेशन को रखने की कोशिश करता हूं।

क्लाइंट के साइट पर Google Analytics, सर्वर के अंत में ऊपर जाने के बाद, 6,000 आगंतुकों को ऑनलाइन दिखाया गया है। यह आंकड़ा तेजी से गिर गया, क्योंकि अनुरोध की प्रासंगिकता, जिसके द्वारा साइट सभी खोज इंजनों के शीर्ष पर थी, हर मिनट खो गई थी। दिन के अंत तक, आगंतुकों की संख्या सात अंकों की हो गई, लेकिन संसाधन का मालिक अभी भी मुझे एक भेड़िया के रूप में देखता है, क्योंकि यह आंकड़ा कई गुना अधिक हो सकता है, साथ ही साथ उसकी आय भी हो सकती है।

इस विन्यास का उपयोग करते हुए, मैं आत्मविश्वास से कह सकता हूं कि सर्वर कई ऐसी साइटों को स्थानांतरित करता है। चूंकि Google समाचार में जोड़ने के बाद मेरे प्रोजेक्ट ने ट्रैफ़िक को बहुत आकर्षित करना शुरू किया, यैंडेक्स ब्लॉग्स के साथ।

मिलियन वर्डप्रेस विज़िटर बनाम सर्वर

More articles: