Nginx वेब सर्वर के प्रदर्शन को अनुकूलित करने के लिए gzip संपीड़न, proxy_buffer सेटिंग्स, worker और keep-alive सेटिंग्स आदि प्रमुख सेटिंग्स को शामिल किया गया है।
विशेष रूप से, डेटा ट्रांसफर मात्रा को कम करने और सर्वर लोड को कम करने के लिए gzip संपीड़न और proxy_buffer बफरिंग, और worker प्रक्रियाओं और keep-alive सेटिंग्स के माध्यम से कनेक्शन प्रबंधन के महत्व पर जोर दिया गया है।
सर्वर वातावरण के अनुसार इष्टतम सेटिंग्स को लागू करने और स्थिर सर्वर संचालन के लिए सावधानियों को प्रस्तुत करने के लिए विभिन्न परीक्षणों को शामिल किया गया है।
Nginx एक ओपन-सोर्स वेब सर्वर या वेब प्रॉक्सी सर्वर है जिसका व्यापक रूप से उपयोग किया जाता है।
उचित कॉन्फ़िगरेशन के साथ, यह स्थिर सामग्री को कुशलतापूर्वक वितरित कर सकता है।
मैं यहाँ कुछ प्रमुख कॉन्फ़िगरेशन सेटिंग्स को रिकॉर्ड करना चाहता हूँ।
प्रदर्शन से संबंधित कुछ प्रमुख सेटिंग्स
1. gzip संपीड़न
जब कोई वेबसाइट लोड होती है, तो वेब सर्वर से जावास्क्रिप्ट, छवियां, HTML, CSS आदि कई फ़ाइलें प्राप्त होती हैं।
इस समय, इन सामग्रियों को मूल रूप में भेजने के बजाय, gzip संपीड़न का उपयोग करके प्रेषित डेटा की मात्रा को महत्वपूर्ण रूप से कम किया जा सकता है।
अर्थात, इसे लागू करने पर
- डेटा की मात्रा कम हो जाती है, जिससे बैंडविड्थ की बचत होती है।
- सर्वर संसाधनों की बचत की जा सकती है।
- उपयोगकर्ता के लिए, वास्तविक लोडिंग गति तेज हो जाती है।
दूसरी ओर, सर्वर को सामग्री का जवाब देने से पहले gzip संपीड़न निष्पादित करना होगा, जिससे सर्वर CPU उपयोग बढ़ सकता है।
किस प्रकार की फ़ाइलों को संपीड़ित किया जाए, संपीड़न स्तर क्या हो, और कितनी बड़ी फ़ाइलों को संपीड़ित किया जाए, जैसे उत्पादन स्तर पर तैनाती से पहले परीक्षण आवश्यक है।
यहाँ gzip से संबंधित कुछ सेटिंग्स दी गई हैं।
gzip on; # gzip संपीड़न सेट करें।
gzip_vary on; # हेडर में Vary: Accept-Encoding जोड़ें।
gzip_proxied any; # यदि nginx को प्रॉक्सी सर्वर के रूप में उपयोग किया जाता है, तो बैकएंड से प्राप्त प्रतिक्रिया को संपीड़ित करें (प्रॉक्सी अनुरोधों के लिए संपीड़न)।
gzip_min_length 256; # केवल 256 बाइट्स या उससे अधिक आकार की फ़ाइलों को संपीड़ित करें।
gzip_comp_level 5; # 1~9 संपीड़न स्तर सेट करें। उच्च स्तर CPU उपयोग को बढ़ाता है। 5 लगभग 50% संपीड़न करता है।
gzip_types text/plain text/css text/xml application/json application/javascript;
// संपीड़ित करने के लिए सामग्री प्रकार सेट करें।
* gzip_vary यह निर्दिष्ट करता है कि क्लाइंट gzip का समर्थन करता है या नहीं, इस पर निर्भर करते हुए, सामग्री को संपीड़ित और असम्पीडित संस्करणों में भेजा जा सकता है। (यह इंगित करता है कि क्लाइंट के अनुरोध शीर्षलेख (Accept-Encoding) के आधार पर सामग्री का एक अलग संस्करण प्रदान किया जा सकता है।)
2. proxy_buffer सेटिंग
Nginx क्लाइंट को प्रतिक्रिया भेजने से पहले प्रतिक्रिया को बफ़र में संग्रहीत करता है।
जब वेब सर्वर क्लाइंट को प्रतिक्रिया भेजता है, तो यदि क्लाइंट की गति धीमी है, तो सर्वर को डेटा भेजने के लिए इंतजार करना होगा (नेटवर्क बॉटलनेक)।
इस समय, सर्वर संसाधनों का लगातार उपयोग किया जाता है, इसलिए क्लाइंट के प्रसंस्करण की गति की परवाह किए बिना प्रतिक्रिया को अस्थायी रूप से संसाधित करने के लिए बफ़र का उपयोग किया जाता है। इससे निम्नलिखित लाभ हैं।
- सर्वर लोड अनुकूलन
- नेटवर्क बॉटलनेक में कमी
location / {
proxy_pass सर्वर url;
# प्रॉक्सी बफ़र सेटिंग्स
proxy_buffering on; # बफ़रिंग सक्षम करें।
proxy_buffer_size 4k; # बफ़र का आकार सेट करें(आमतौर पर हेडर के लिए)।
proxy_buffers 8 4k; # प्रत्येक कनेक्शन के लिए बफ़र की संख्या और आकार(8 4kb बफ़र) proxy_busy_buffers_size 8k; # क्लाइंट को प्रतिक्रिया भेजने के दौरान उपयोग किए जा सकने वाले अधिकतम बफ़र आकार
}
※ यदि बफ़र आकार बहुत बड़ा है, तो वास्तविक समय डेटा ट्रांसमिशन जैसे टेक्स्ट स्ट्रीमिंग में देरी हो सकती है, इसलिए परीक्षण आवश्यक है। विशेष रूप से, हाल ही में कई AI-संबंधित सेवाएँ सामने आई हैं, इसलिए यदि टेक्स्ट स्ट्रीमिंग काम नहीं कर रही है, तो इस सेटिंग की जाँच करें।
3. वर्कर और HTTP सेटिंग्स
वर्कर क्लाइंट अनुरोधों को संसाधित करने वाली प्रक्रियाएँ हैं, और आप यह निर्दिष्ट कर सकते हैं कि सर्वर के प्रत्येक CPU कोर में कितने वर्कर हैं।
HTTP आम तौर पर अनुरोध-कनेक्शन-प्रतिक्रिया-कनेक्शन समापन होता है, लेकिन कई अनुरोधों के लिए कनेक्शन संसाधनों को कम करने के लिए, क्लाइंट कनेक्शन को बनाए रखा जा सकता है। यह keep-alive सेटिंग है।
worker_processes auto; # उपलब्ध CPU कोर की संख्या के अनुसार स्वचालित रूप से सेट करें।
worker_connections 1024; # प्रत्येक वर्कर द्वारा एक साथ संभाले जा सकने वाले कनेक्शन की संख्या।
# keep-alive सेटिंग्स
keepalive_timeout 65;
keepalive_requests 100;
server {
listen 80;
location / {
proxy_pass सर्वर url;
}
}
ऊपर दोनों को एक साथ जोड़ने का कारण इस प्रकार है।
यदि आपके सर्वर में 4 कोर हैं, तो सैद्धांतिक रूप से संभव कनेक्शन की संख्या 1,024 * 4 = 4,096 है।
(संसाधनों या ट्रैफ़िक वातावरण के आधार पर, यह सटीक नहीं हो सकता है।)
जब 4,096 क्लाइंट एक साथ कनेक्ट होते हैं और 65 सेकंड के लिए सभी keep-alive को रखते हैं,
4,097वें उपयोगकर्ता के कनेक्ट करने का प्रयास करने पर, कनेक्शन विफल हो सकता है, जिससे प्रतिक्रिया में देरी हो सकती है।
इसलिए, यह मानते हुए कि ऑटो स्केलिंग आदि के साथ सर्वर संसाधन स्थिर हैं, यदि ईवेंट के दौरान प्रतिक्रिया में देरी होती है, तो उपरोक्त सेटिंग का अप्रत्यक्ष प्रभाव पड़ सकता है।
4. अन्य - location ब्लॉक
प्रॉक्सी बफ़र जैसी कुछ सेटिंग्स को अनुरोध URL के अनुसार लागू किया जा सकता है।
* keep-alive जैसी कुछ सेटिंग्स HTTP/सर्वर स्तर पर लागू होती हैं और ब्लॉक के अनुसार सेट नहीं की जा सकती हैं।
ऊपर दी गई सेटिंग्स का उपयोग करके, आप वेब प्रदर्शन को अनुकूलित कर सकते हैं। विभिन्न परीक्षण मामलों पर विचार करें और सर्वर प्रदर्शन को अनुकूलित करने के लिए पर्याप्त परीक्षण करें!
* आप सर्वर डाउनटाइम के बिना संशोधित nginx कॉन्फ़िगरेशन लागू कर सकते हैं, इसलिए यह काफी स्थिर है।