इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

Katie Hempenius

खास जानकारी

इस गाइड में, चार चरणों में ओवरलोड किए गए सर्वर को ठीक करने का तरीका बताया गया है:

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

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

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

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

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

ठीक करें

अगर आपके पास सीमित समय है, तो…

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

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

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

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

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

इस बारे में ज़्यादा जानकारी के लिए:

JS और CSS को छोटा करना

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

ज्ञात करना

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

ठीक करें

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

निगरानी

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

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

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

ठीक करें

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

निर्देश: