Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

सर्वर से ज़्यादा लोड होने की समस्या को ठीक करना

सर्वर की बॉटलनेक पहचानने, इसे फटाफट ठीक करने, सर्वर की परफ़ॉर्मेंस सुधारने, और रिग्रेशन को रोकने का तरीका.

Katie Hempenius

खास जानकारी

इस गाइड में, सर्वर पर लोड ज़्यादा होने की समस्या को चार चरणों में ठीक करने का तरीका बताया गया है:

आकलन करना: सर्वर की बॉटलनेक का पता लगाएं.
जोखिम कम करना: असर को कम करने के लिए, तुरंत समाधान लागू करें.
बेहतर बनाएं: सर्वर की क्षमताओं को बढ़ाएं और उन्हें ऑप्टिमाइज़ करें.
मॉनिटर करना: आने वाले समय में होने वाली समस्याओं से बचने के लिए, ऑटोमेटेड टूल का इस्तेमाल करें.

मूल्यांकन करें

जब किसी सर्वर पर ट्रैफ़िक बहुत ज़्यादा हो जाता है, तो इनमें से एक या उससे ज़्यादा चीज़ें रुकावट बन सकती हैं: सीपीयू, नेटवर्क, मेमोरी या डिस्क I/O. इनमें से कौनसी समस्या सबसे ज़्यादा असर डाल रही है, यह पता लगाने से जोखिम कम करने के सबसे असरदार तरीकों पर ध्यान दिया जा सकता है.

सीपीयू: अगर सीपीयू का इस्तेमाल लगातार 80% से ज़्यादा हो रहा है, तो इसकी जांच करके समस्या को ठीक किया जाना चाहिए. सीपीयू का इस्तेमाल 80 से 90% तक पहुंचने पर, सर्वर की परफ़ॉर्मेंस अक्सर कम हो जाती है. साथ ही, सीपीयू का इस्तेमाल 100% के करीब पहुंचने पर, सर्वर की परफ़ॉर्मेंस और भी खराब हो जाती है. एक अनुरोध को पूरा करने के लिए सीपीयू का इस्तेमाल न के बराबर होता है. हालांकि, ट्रैफ़िक में बढ़ोतरी के दौरान ऐसा करने से, कभी-कभी सर्वर पर ज़्यादा लोड पड़ सकता है. सीपीयू के इस्तेमाल को कम करने के लिए, अन्य इन्फ़्रास्ट्रक्चर पर लोड को ऑफ़लोड करें, ज़्यादा खर्च वाले ऑपरेशन कम करें, और अनुरोधों की संख्या को सीमित करें.
नेटवर्क: ज़्यादा ट्रैफ़िक होने पर, उपयोगकर्ताओं के अनुरोधों को पूरा करने के लिए ज़रूरी नेटवर्क थ्रूपुट, क्षमता से ज़्यादा हो सकता है. सर्वर देने वाली संस्था के आधार पर, कुछ साइटों पर कुल डेटा ट्रांसफ़र की सीमाएं भी लागू हो सकती हैं. सर्वर पर भेजे जाने वाले और सर्वर से मिलने वाले डेटा के साइज़ और संख्या को कम करके, इस समस्या को हल किया जा सकता है.
मेमोरी: जब किसी सिस्टम में ज़रूरत के मुताबिक मेमोरी नहीं होती, तो डेटा को डिस्क में सेव करना पड़ता है. डिस्क को ऐक्सेस करने में मेमोरी की तुलना में ज़्यादा समय लगता है. इससे पूरा ऐप्लिकेशन धीमा हो सकता है. अगर मेमोरी पूरी तरह से भर जाती है, तो आउट ऑफ़ मेमोरी (ओओएम) की गड़बड़ियां हो सकती हैं. मेमोरी के बंटवारे में बदलाव करके, मेमोरी लीक की समस्या को ठीक करके, और मेमोरी को अपग्रेड करके, इस समस्या को हल किया जा सकता है.
डिस्क I/O: डिस्क से डेटा को पढ़ने या लिखने की दर, डिस्क की क्षमता पर निर्भर करती है. अगर डिस्क इनपुट/आउटपुट की वजह से समस्या आ रही है, तो कैश मेमोरी में सेव किए गए डेटा की मात्रा बढ़ाकर इस समस्या को कम किया जा सकता है. हालांकि, इससे मेमोरी का इस्तेमाल बढ़ जाएगा. अगर इससे समस्या हल नहीं होती है, तो आपको अपनी डिस्क अपग्रेड करनी पड़ सकती हैं.

इस गाइड में बताई गई तकनीकों का मकसद, सीपीयू और नेटवर्क की रुकावटों को दूर करना है. ज़्यादातर साइटों के लिए, ट्रैफ़िक में बढ़ोतरी के दौरान सीपीयू और नेटवर्क सबसे ज़्यादा रुकावटें पैदा करेंगे.

जिस सर्वर पर असर पड़ा है उस पर top चलाकर, रुकावटों की जांच की जा सकती है. अगर उपलब्ध हो, तो इसे सर्वर देने वाली संस्था या मॉनिटरिंग टूल से मिले पुराने डेटा के साथ जोड़ें.

स्थिर करें

ओवरलोड सर्वर की वजह से, सिस्टम में कहीं और एक के बाद एक गड़बड़ियां हो सकती हैं. इसलिए, कोई और अहम बदलाव करने से पहले, सर्वर को स्थिर करना ज़रूरी है.

अनुरोध संख्या सीमित करना

अनुरोध संख्या सीमित करने की सुविधा, आने वाले अनुरोधों की संख्या को सीमित करके इन्फ़्रास्ट्रक्चर को सुरक्षित रखती है. सर्वर की परफ़ॉर्मेंस खराब होने पर, यह और भी ज़रूरी हो जाता है: जवाब मिलने में लगने वाला समय बढ़ने पर, उपयोगकर्ता पेज को बार-बार रीफ़्रेश करते हैं. इससे सर्वर पर लोड और बढ़ जाता है.

ठीक करें

अनुरोध को अस्वीकार करना आसान है, लेकिन अपने सर्वर को सुरक्षित रखने का सबसे अच्छा तरीका यह है कि अनुरोध संख्या सीमित करने की सुविधा को सर्वर से पहले ही लागू कर दिया जाए. उदाहरण के लिए, लोड बैलेंसर, रिवर्स प्रॉक्सी या सीडीएन के ज़रिए.

निर्देश:

इस बारे में और पढ़ें:

अनुरोध संख्या सीमित करने की रणनीतियां और तकनीकें

एचटीटीपी को कैश मेमोरी में सेव करना

कॉन्टेंट को ज़्यादा तेज़ी से कैश मेमोरी में सेव करने के तरीके खोजें. अगर किसी रिसॉर्स को एचटीटीपी कैश मेमोरी (चाहे वह ब्राउज़र की कैश मेमोरी हो या सीडीएन) से दिखाया जा सकता है, तो उसे मूल सर्वर से अनुरोध करने की ज़रूरत नहीं होती. इससे सर्वर पर लोड कम हो जाता है.

Cache-Control, Expires, और ETag जैसे एचटीटीपी हेडर से पता चलता है कि एचटीटीपी कैश मेमोरी में किसी संसाधन को कैसे कैश किया जाना चाहिए. इन हेडर की जांच करने और उन्हें ठीक करने से, कैश मेमोरी में डेटा सेव करने की प्रोसेस बेहतर होगी.

हालांकि, सर्विस वर्कर का इस्तेमाल कैश मेमोरी में डेटा सेव करने के लिए भी किया जा सकता है. इसके लिए, वे एक अलग कैश मेमोरी का इस्तेमाल करते हैं. साथ ही, वे एचटीटीपी कैश मेमोरी को बदलने के बजाय, उसे बेहतर बनाते हैं. इस वजह से, ओवरलोड सर्वर को मैनेज करते समय, एचटीटीपी कैश मेमोरी को ऑप्टिमाइज़ करने पर ध्यान देना चाहिए.

ज्ञात करना

Lighthouse चलाएं और कैश मेमोरी की बेहतर नीति के साथ स्टैटिक ऐसेट दिखाएं ऑडिट देखें. इससे आपको कम से मध्यम टाइम टू लाइव (टीटीएल) वाले संसाधनों की सूची दिखेगी. सूची में शामिल हर संसाधन के लिए, देखें कि क्या TTL को बढ़ाया जाना चाहिए. मोटे तौर पर, ये दिशा-निर्देश अपनाए जा सकते हैं:

स्टैटिक रिसॉर्स को लंबे टीटीएल (एक साल) के साथ कैश मेमोरी में सेव किया जाना चाहिए.
डाइनैमिक संसाधनों को कम टीटीएल (तीन घंटे) के साथ कैश मेमोरी में सेव किया जाना चाहिए.

ठीक करें

Cache-Control हेडर के max-age डायरेक्टिव को सही सेकंड पर सेट करें.

निर्देश:

अनुकूल गिरावट

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

बेहतर बनाएं

कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) का इस्तेमाल करना

स्टैटिक ऐसेट को आपके सर्वर से कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) पर ऑफ़लोड किया जा सकता है. इससे सर्वर पर लोड कम हो जाता है.

सीडीएन का मुख्य काम, उपयोगकर्ताओं को तेज़ी से कॉन्टेंट उपलब्ध कराना है. इसके लिए, वह उपयोगकर्ताओं के आस-पास मौजूद सर्वर के बड़े नेटवर्क का इस्तेमाल करता है. हालांकि, ज़्यादातर सीडीएन, परफ़ॉर्मेंस से जुड़ी अन्य सुविधाएं भी देते हैं. जैसे, कंप्रेस करना, लोड बैलेंस करना, और मीडिया ऑप्टिमाइज़ेशन.

सीडीएन सेट अप करना

सीडीएन को बड़े पैमाने पर इस्तेमाल करने से फ़ायदा मिलता है. इसलिए, अपना सीडीएन इस्तेमाल करने से शायद ही कोई फ़ायदा हो. सीडीएन का बुनियादी कॉन्फ़िगरेशन सेट अप करने में ज़्यादा समय नहीं लगता है. इसमें करीब 30 मिनट लगते हैं. इसमें सीडीएन पर ले जाने के लिए, डीएनएस रिकॉर्ड अपडेट करना शामिल है.

सीडीएन के इस्तेमाल को ऑप्टिमाइज़ करना

ज्ञात करना

WebPageTest चलाकर, उन संसाधनों की पहचान करें जिन्हें सीडीएन से नहीं दिखाया जा रहा है, लेकिन दिखाया जाना चाहिए. नतीजों वाले पेज पर, 'सीडीएन का असरदार इस्तेमाल' के ऊपर मौजूद स्क्वेयर पर क्लिक करें. इससे आपको उन संसाधनों की सूची दिखेगी जिन्हें सीडीएन से दिखाया जाना चाहिए.

'सीडीएन का असरदार तरीके से इस्तेमाल' बटन की ओर इशारा करता हुआ ऐरो — WebPageTest के नतीजे

ठीक करें

अगर सीडीएन किसी संसाधन को कैश मेमोरी में सेव नहीं कर रहा है, तो देखें कि ये शर्तें पूरी हो रही हैं या नहीं:

इसमें Cache-Control: public हेडर है.
इसमें Cache-Control: s-maxage, Cache-Control: max-age या Expires हेडर है.
इसमें Content-Length, Content-Range या Transfer-Encoding header है.

कंप्यूट संसाधनों को स्केल करना

कंप्यूट संसाधनों को बढ़ाने का फ़ैसला सोच-समझकर लेना चाहिए. हालांकि, कंप्यूटिंग संसाधनों को बढ़ाना अक्सर ज़रूरी होता है, लेकिन समय से पहले ऐसा करने से, आर्किटेक्चर में बेवजह की जटिलता और वित्तीय लागतें बढ़ सकती हैं.

ज्ञात करना

टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) ज़्यादा होने का मतलब है कि सर्वर की क्षमता खत्म होने वाली है. यह जानकारी, Lighthouse के सर्वर से जवाब मिलने में लगने वाले समय (टीटीएफ़बी) को कम करें ऑडिट में देखी जा सकती है.

ज़्यादा जानकारी पाने के लिए, सीपीयू के इस्तेमाल का आकलन करने वाले मॉनिटरिंग टूल का इस्तेमाल करें. अगर सीपीयू का मौजूदा या अनुमानित इस्तेमाल 80% से ज़्यादा है, तो आपको अपने सर्वर बढ़ाने चाहिए.

ठीक करें

लोड बैलेंसर जोड़ने से, ट्रैफ़िक को कई सर्वर पर डिस्ट्रिब्यूट किया जा सकता है. लोड बैलेंसर, सर्वर के पूल के सामने मौजूद होता है और ट्रैफ़िक को सही सर्वर पर भेजता है. क्लाउड सेवा देने वाली कंपनियां, अपने लोड बैलेंसर (GCP, AWS, Azure) उपलब्ध कराती हैं. इसके अलावा, HAProxy या NGINX का इस्तेमाल करके, अपना लोड बैलेंसर सेट अप किया जा सकता है. लोड बैलेंसर सेट अप करने के बाद, अतिरिक्त सर्वर जोड़े जा सकते हैं.

लोड बैलेंसिंग के अलावा, क्लाउड सेवा देने वाली ज़्यादातर कंपनियां, ऑटो स्केलिंग (GCP, AWS, Azure) भी देती हैं. ऑटोस्केलिंग, लोड बैलेंसिंग के साथ काम करती है. ऑटोस्केलिंग, किसी तय समय पर मांग के हिसाब से कंप्यूट रिसॉर्स को अपने-आप बढ़ाता और घटाता है. हालांकि, ऑटोस्केलिंग कोई जादू नहीं है. नए इंस्टेंस को ऑनलाइन आने में समय लगता है और इसके लिए काफ़ी कॉन्फ़िगरेशन की ज़रूरत होती है. ऑटो स्केलिंग की अतिरिक्त जटिलता के कारण, पहले लोड बैलेंसर पर आधारित आसान सेटअप पर विचार करना चाहिए.

संपीड़न सक्षम करें

टेक्स्ट वाले संसाधनों को gzip या brotli का इस्तेमाल करके कंप्रेस किया जाना चाहिए. Gzip, इन रिसॉर्स के ट्रांसफ़र साइज़ को करीब 70% तक कम कर सकता है.

ज्ञात करना

Lighthouse के टेक्स्ट कंप्रेस करने की सुविधा चालू करें ऑडिट का इस्तेमाल करके, उन रिसॉर्स की पहचान करें जिन्हें कंप्रेस किया जाना चाहिए.

ठीक करें

अपने सर्वर कॉन्फ़िगरेशन को अपडेट करके, कंप्रेस करने की सुविधा चालू करें. निर्देश:

इमेज और मीडिया को ऑप्टिमाइज़ करना

ज़्यादातर वेबसाइटों में, फ़ाइल के साइज़ का ज़्यादातर हिस्सा इमेज का होता है. इमेज को ऑप्टिमाइज़ करने से, साइट का साइज़ तेज़ी से और काफ़ी कम किया जा सकता है.

ज्ञात करना

Lighthouse में कई तरह के ऑडिट होते हैं, जो इमेज ऑप्टिमाइज़ेशन की संभावनाओं को फ़्लैग करते हैं. इसके अलावा, DevTools का इस्तेमाल करके सबसे बड़ी इमेज फ़ाइलों की पहचान की जा सकती है. ये इमेज, ऑप्टिमाइज़ेशन के लिए सही विकल्प हो सकती हैं.

Lighthouse के काम के ऑडिट:

Chrome DevTools वर्कफ़्लो:

नेटवर्क पर की गई गतिविधियों को लॉग करना
इमेज के अलावा अन्य रिसॉर्स को फ़िल्टर करने के लिए, Img पर क्लिक करें
इमेज फ़ाइलों को साइज़ के हिसाब से क्रम में लगाने के लिए, साइज़ कॉलम पर क्लिक करें

ठीक करें

अगर आपके पास कम समय है…

बड़ी और बार-बार लोड होने वाली इमेज की पहचान करने पर ध्यान दें. साथ ही, Squoosh जैसे टूल की मदद से, उन्हें मैन्युअल तरीके से ऑप्टिमाइज़ करें. आम तौर पर, हीरो इमेज को ऑप्टिमाइज़ करना फ़ायदेमंद होता है.

ध्यान रखने वाली बातें:

साइज़: इमेज का साइज़ ज़रूरत से ज़्यादा नहीं होना चाहिए.
कंप्रेशन: आम तौर पर, 80 से 85 के क्वालिटी लेवल से इमेज की क्वालिटी पर बहुत कम असर पड़ता है. हालांकि, इससे फ़ाइल का साइज़ 30 से 40% तक कम हो जाता है.
फ़ॉर्मैट: फ़ोटो के लिए PNG के बजाय JPEG का इस्तेमाल करें. ऐनिमेटेड कॉन्टेंट के लिए GIF के बजाय MP4 का इस्तेमाल करें.

अगर आपके पास ज़्यादा समय है…

अगर आपकी साइट पर इमेज काफ़ी ज़्यादा हैं, तो इमेज सीडीएन सेट अप करें. इमेज सीडीएन को इमेज दिखाने और उन्हें ऑप्टिमाइज़ करने के लिए डिज़ाइन किया गया है. ये मूल सर्वर से इमेज दिखाने का काम अपने ऊपर ले लेते हैं. इमेज सीडीएन को सेट अप करना आसान है. हालांकि, इसके लिए मौजूदा इमेज के यूआरएल को अपडेट करना होगा, ताकि वे इमेज सीडीएन पर ले जाएं.

इस बारे में और पढ़ें:

JS और सीएसएस फ़ाइलों का साइज़ कम करना

काट-छांट करने से, JavaScript और सीएसएस से ग़ैर-ज़रूरी वर्ण हट जाते हैं.

ज्ञात करना

सीएसएस फ़ाइलों का साइज़ कम करें और JavaScript फ़ाइलों का साइज़ कम करें Lighthouse ऑडिट का इस्तेमाल करके, उन रिसॉर्स की पहचान करें जिनका साइज़ कम करना ज़रूरी है.

ठीक करें

अगर आपके पास समय कम है, तो JavaScript को छोटा करने पर ध्यान दें. ज़्यादातर साइटों में सीएसएस के मुकाबले JavaScript ज़्यादा होता है. इसलिए, इसका ज़्यादा असर होगा.

निगरानी

सर्वर मॉनिटरिंग टूल, डेटा कलेक्शन, डैशबोर्ड, और सर्वर की परफ़ॉर्मेंस के बारे में सूचना देने की सुविधा देते हैं. इनका इस्तेमाल करने से, आने वाले समय में सर्वर की परफ़ॉर्मेंस से जुड़ी समस्याओं को रोकने और उन्हें कम करने में मदद मिल सकती है.

मॉनिटरिंग सेटअप को जितना हो सके उतना आसान रखना चाहिए. बहुत ज़्यादा डेटा इकट्ठा करने और सूचनाएं भेजने की अपनी लागत होती है: डेटा इकट्ठा करने का दायरा या फ़्रीक्वेंसी जितनी ज़्यादा होगी, उसे इकट्ठा करने और सेव करने में उतना ही ज़्यादा खर्च आएगा. बहुत ज़्यादा सूचनाएं भेजने से, पेजों को अनदेखा किया जा सकता है.

सूचना देने के लिए, ऐसी मेट्रिक का इस्तेमाल किया जाना चाहिए जो समस्याओं का लगातार और सटीक तरीके से पता लगाती हों. सर्वर के रिस्पॉन्स टाइम (लेटेंसी) की मेट्रिक, इस काम के लिए काफ़ी कारगर है: इससे कई तरह की समस्याओं का पता चलता है. साथ ही, यह सीधे तौर पर उपयोगकर्ता अनुभव से जुड़ी होती है. सीपीयू के इस्तेमाल जैसी कम लेवल की मेट्रिक के आधार पर सूचनाएं देना, एक मददगार तरीका हो सकता है. हालांकि, इससे समस्याओं के एक छोटे सबसेट का ही पता चलेगा. इसके अलावा, सूचनाएं औसत के बजाय, टेल पर देखी गई परफ़ॉर्मेंस (दूसरे शब्दों में, 95वें या 99वें पर्सेंटाइल) पर आधारित होनी चाहिए. ऐसा न करने पर, औसत वैल्यू की वजह से उन समस्याओं का पता लगाना मुश्किल हो सकता है जो सभी उपयोगकर्ताओं पर असर नहीं डालती हैं.

ठीक करें

क्लाउड सेवा देने वाली सभी मुख्य कंपनियां, मॉनिटरिंग के लिए अपने टूल उपलब्ध कराती हैं (GCP, AWS, Azure). इसके अलावा, Netdata एक बेहतरीन मुफ़्त और ओपन-सोर्स विकल्प है. चाहे कोई भी टूल चुना जाए, आपको हर उस सर्वर पर टूल का मॉनिटरिंग एजेंट इंस्टॉल करना होगा जिसकी आपको निगरानी करनी है. यह प्रोसेस पूरी होने के बाद, सूचनाएं पाने की सुविधा सेट अप करें.

निर्देश: