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

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

खास जानकारी

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

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

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

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

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

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

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

स्थिर करें

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

दर को सीमित करना

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

समाधान

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

निर्देश:

• एनजीएनएक्स
• HAProxy
• Microsoft IIS

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

• रेट-सीमित रणनीतियां और तकनीक

एचटीटीपी कैश मेमोरी

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

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

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

ज्ञात करना

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

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

समाधान

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

निर्देश:

• एनजीएनएक्स
• Apache
• Microsoft

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

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

बेहतर बनाएं

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

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

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

CDN सेट अप करें

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

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

ज्ञात करना

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

समाधान

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

• इसमें एक Cache-Control: public हेडर है.
• इसमें Cache-Control: s-maxage, Cache-Control: max-age या Expires हेडर होता है.
• इसमें Content-Length, Content-Range या Transfer-Encoding header शामिल है.

स्केल कंप्यूट रिसोर्स

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

ज्ञात करना

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

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

समाधान

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

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

कंप्रेस करना चालू करें

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

ज्ञात करना

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

समाधान

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

• एनजीएनएक्स
• Apache
• Microsoft

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

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

ज्ञात करना

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

लाइटहाउस ऑडिट:

• सही साइज़ वाली इमेज
• ऑफ़स्क्रीन इमेज को रोकें
• इमेज को बेहतर तरीके से कोड में बदलना
• अगली-पीढ़ी की टेक्नोलॉजी वाले फ़ॉर्मैट में इमेज दिखाना
• ऐनिमेट किए गए वीडियो के लिए वीडियो फ़ॉर्मैट इस्तेमाल करना

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

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

समाधान

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

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

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

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

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

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

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

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

JS और सीएसएस कम करें

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

ज्ञात करना

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

समाधान

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

• JavaScript को छोटा करना
• सीएसएस को छोटा करें

मॉनिटर करना

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

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

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

समाधान

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

निर्देश:

• GCP
• AWS
• Azure
• नेटडेटा