Nginx को वेब सर्वर के रूप में उपयोग करते समय प्रमुख सेटिंग्स

Nginx एक ओपन-सोर्स वेब सर्वर या वेब प्रॉक्सी सर्वर है जिसका व्यापक रूप से उपयोग किया जाता है।

उचित कॉन्फ़िगरेशन के साथ, यह स्थिर सामग्री को कुशलतापूर्वक वितरित कर सकता है।

मैं यहाँ कुछ प्रमुख कॉन्फ़िगरेशन सेटिंग्स को रिकॉर्ड करना चाहता हूँ।

प्रदर्शन से संबंधित कुछ प्रमुख सेटिंग्स

1. gzip संपीड़न

जब कोई वेबसाइट लोड होती है, तो वेब सर्वर से जावास्क्रिप्ट, छवियां, HTML, CSS आदि कई फ़ाइलें प्राप्त होती हैं।

इस समय, इन सामग्रियों को मूल रूप में भेजने के बजाय, gzip संपीड़न का उपयोग करके प्रेषित डेटा की मात्रा को महत्वपूर्ण रूप से कम किया जा सकता है।

अर्थात, इसे लागू करने पर

- डेटा की मात्रा कम हो जाती है, जिससे बैंडविड्थ की बचत होती है।

- सर्वर संसाधनों की बचत की जा सकती है।

- उपयोगकर्ता के लिए, वास्तविक लोडिंग गति तेज हो जाती है।

दूसरी ओर, सर्वर को सामग्री का जवाब देने से पहले gzip संपीड़न निष्पादित करना होगा, जिससे सर्वर CPU उपयोग बढ़ सकता है।

किस प्रकार की फ़ाइलों को संपीड़ित किया जाए, संपीड़न स्तर क्या हो, और कितनी बड़ी फ़ाइलों को संपीड़ित किया जाए, जैसे उत्पादन स्तर पर तैनाती से पहले परीक्षण आवश्यक है।

यहाँ gzip से संबंधित कुछ सेटिंग्स दी गई हैं।

* gzip_vary यह निर्दिष्ट करता है कि क्लाइंट gzip का समर्थन करता है या नहीं, इस पर निर्भर करते हुए, सामग्री को संपीड़ित और असम्पीडित संस्करणों में भेजा जा सकता है। (यह इंगित करता है कि क्लाइंट के अनुरोध शीर्षलेख (Accept-Encoding) के आधार पर सामग्री का एक अलग संस्करण प्रदान किया जा सकता है।)

2. proxy_buffer सेटिंग

Nginx क्लाइंट को प्रतिक्रिया भेजने से पहले प्रतिक्रिया को बफ़र में संग्रहीत करता है।

जब वेब सर्वर क्लाइंट को प्रतिक्रिया भेजता है, तो यदि क्लाइंट की गति धीमी है, तो सर्वर को डेटा भेजने के लिए इंतजार करना होगा (नेटवर्क बॉटलनेक)।

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

- सर्वर लोड अनुकूलन

- नेटवर्क बॉटलनेक में कमी

※ यदि बफ़र आकार बहुत बड़ा है, तो वास्तविक समय डेटा ट्रांसमिशन जैसे टेक्स्ट स्ट्रीमिंग में देरी हो सकती है, इसलिए परीक्षण आवश्यक है। विशेष रूप से, हाल ही में कई AI-संबंधित सेवाएँ सामने आई हैं, इसलिए यदि टेक्स्ट स्ट्रीमिंग काम नहीं कर रही है, तो इस सेटिंग की जाँच करें।

3. वर्कर और HTTP सेटिंग्स

वर्कर क्लाइंट अनुरोधों को संसाधित करने वाली प्रक्रियाएँ हैं, और आप यह निर्दिष्ट कर सकते हैं कि सर्वर के प्रत्येक CPU कोर में कितने वर्कर हैं।

HTTP आम तौर पर अनुरोध-कनेक्शन-प्रतिक्रिया-कनेक्शन समापन होता है, लेकिन कई अनुरोधों के लिए कनेक्शन संसाधनों को कम करने के लिए, क्लाइंट कनेक्शन को बनाए रखा जा सकता है। यह keep-alive सेटिंग है।

ऊपर दोनों को एक साथ जोड़ने का कारण इस प्रकार है।

यदि आपके सर्वर में 4 कोर हैं, तो सैद्धांतिक रूप से संभव कनेक्शन की संख्या 1,024 * 4 = 4,096 है।

(संसाधनों या ट्रैफ़िक वातावरण के आधार पर, यह सटीक नहीं हो सकता है।)

जब 4,096 क्लाइंट एक साथ कनेक्ट होते हैं और 65 सेकंड के लिए सभी keep-alive को रखते हैं,

4,097वें उपयोगकर्ता के कनेक्ट करने का प्रयास करने पर, कनेक्शन विफल हो सकता है, जिससे प्रतिक्रिया में देरी हो सकती है।

इसलिए, यह मानते हुए कि ऑटो स्केलिंग आदि के साथ सर्वर संसाधन स्थिर हैं, यदि ईवेंट के दौरान प्रतिक्रिया में देरी होती है, तो उपरोक्त सेटिंग का अप्रत्यक्ष प्रभाव पड़ सकता है।

4. अन्य - location ब्लॉक

प्रॉक्सी बफ़र जैसी कुछ सेटिंग्स को अनुरोध URL के अनुसार लागू किया जा सकता है।

* keep-alive जैसी कुछ सेटिंग्स HTTP/सर्वर स्तर पर लागू होती हैं और ब्लॉक के अनुसार सेट नहीं की जा सकती हैं।

server {
listen 80;
server_name example.com;

ऊपर दी गई सेटिंग्स का उपयोग करके, आप वेब प्रदर्शन को अनुकूलित कर सकते हैं। विभिन्न परीक्षण मामलों पर विचार करें और सर्वर प्रदर्शन को अनुकूलित करने के लिए पर्याप्त परीक्षण करें!

* आप सर्वर डाउनटाइम के बिना संशोधित nginx कॉन्फ़िगरेशन लागू कर सकते हैं, इसलिए यह काफी स्थिर है।