जब मुझे uWSGI है तो मुझे nginx की आवश्यकता क्यों है

Question

जब मैं Django एप्लिकेशन को तैनात करना चाहता हूं, तो uWGSI के साथ सहयोग करने के लिए nginx को कॉन्फ़िगर करने के तरीके पर कई ट्यूटोरियल हैं।

लेकिन मुझे इस किट में नगीनक्स की आवश्यकता क्यों है? uWSGI ही WSGI पायथन एप्लिकेशन की सेवा कर सकता है, यह स्थैतिक फाइलों को सेवा दे सकता है, यह एसएसएल भी कर सकता है। नगनेक्स क्या कर सकता है जो uWSGI नहीं कर सकता है?

Comments

मैं देख सकता हूं कि यह प्रश्न राय आधारित है। मैं बिल्कुल असहमत हूं। प्रश्न "नग्नेक्स क्या कर सकता है जो uWSGI नहीं कर सकता है?" तथ्य आधारित है।

— user983447

मैं आम तौर पर फिर से खोलने के लिए नहीं बोलता, लेकिन इस मामले में मैं सहमत हूं। मौजूदा उत्क्रमित और स्वीकृत उत्तर एक अच्छा है, जो दर्शाता है कि प्रश्न, जैसा कि लिखा गया है, समझदार और प्रासंगिक उत्तरों की प्रशंसा करता है; मुझे लगता है कि शायद यह एक अच्छा सवाल है।

— MadHatter

Answer 1

तुम नहीं।

यह सरल जवाब है, वैसे भी - आपको इसकी आवश्यकता नहीं है। uWSGI अपने आप में एक सक्षम सर्वर है।

हालांकि, नगनेक्स जैसे अन्य सर्वर लंबे समय तक रहे हैं और (शायद, वैसे भी) अधिक सुरक्षित हैं, साथ ही साथ यूडब्ल्यूएसजीआई द्वारा समर्थित अतिरिक्त सुविधाएँ नहीं हैं - उदाहरण के लिए, स्थैतिक संसाधनों की बेहतर हैंडलिंग (एक्सपायर्स या ई-टैग के किसी भी संयोजन के माध्यम से) हेडर, gzip संपीड़न, पूर्व-संकुचित gzip, आदि) जो सर्वर और नेटवर्क लोड को काफी कम कर सकता है; इसके अतिरिक्त, आपके Django एप्लिकेशन के सामने nginx जैसा सर्वर आपकी डायनामिक सामग्री के कैशिंग को लागू कर सकता है, साथ ही सर्वर लोड को कम करने में मदद कर सकता है, और यहां तक ​​कि CDN के उपयोग को सुविधाजनक बनाने में भी मदद करता है (जो आमतौर पर डायनामिक सामग्री के साथ अच्छा नहीं करता है )। आप और भी आगे बढ़ सकते हैं और पूरी तरह से अलग सर्वर पर nginx कर सकते हैं, गतिशील सामग्री के लिए गतिशील प्रॉक्सी के लिए रिवर्स प्रॉक्सी अनुरोध स्थैतिक सामग्री को स्वयं संभालते हुए लोड सर्वर के संतुलित क्लस्टर में कर सकते हैं।

उदाहरण के लिए, मेरा ब्लॉग (जबकि यह वर्डप्रेस है, इसके सामने nginx है) को 24 घंटे के लिए कैश पोस्ट और 5 मिनट के लिए इंडेक्स पेजों को कैश करने के लिए तैयार किया गया है; जबकि मुझे उस समय के लिए पर्याप्त ट्रैफ़िक दिखाई नहीं देता है, लेकिन यह मेरे छोटे छोटे VPS मौसम को कभी-कभी बढ़ने में मदद करता है जो अन्यथा इसे नीचे गिरा सकता है - जैसे कि ट्रैफ़िक का बड़ा उछाल जब मेरा एक लेख उठाया गया। कई हजारों अनुयायियों के साथ एक ट्विटरर द्वारा, जिनमें से कई ने अपने हजारों अनुयायियों को फिर से ट्वीट किया।

अगर मैं एक "नंगे" uWSGI सर्वर चला रहा था (और यह मानते हुए कि यह एक Django साइट थी, वर्डप्रेस के बजाय), तो यह ठीक हो सकता है - या दुर्घटनाग्रस्त हो गया और जल गया हो सकता है, मुझे लापता आगंतुकों की कीमत चुकानी होगी । उस भार को संभालने के लिए उसके सामने nginx होने से वास्तव में मदद मिल सकती है।

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

Comments

एक बात जो दिमाग में आती है कि मुझे लगता है कि उनके जवाब में @Kromey ने जो कवर किया है, उसके अलावा यह ध्यान देने योग्य है कि uWSGI के लिए देशी प्रोटोकॉल http नहीं है, बल्कि uwsgi प्रोटोकॉल है। Uwsgi प्रोटोकॉल http से निपटने के लिए सरल और अधिक कुशल है और इस प्रकार आपके uWSGI एप्लिकेशन के सामने एक अधिक पूर्ण विशेषताओं वाला वेब सर्वर (nginx या whatnot) चिपका हुआ है, जो वास्तव में बहुत अधिक प्रसंस्करण की नकल नहीं करता है और आपके आधार पर महत्वपूर्ण परिणाम प्रदान कर सकता है। की जरूरत है।

— हाकिन लिंडक्विस्ट

@ HåkanLindqvist बिल्कुल सही है; बस स्पष्ट करने के लिए, uWSGI HTTP को "बोलने" में पूरी तरह से सक्षम है, इसलिए, यह अपने आप ठीक हो सकता है, लेकिन हां यह ध्यान देने योग्य है कि इसके सामने एक वेब सर्वर, HTTP नहीं, बल्कि uwsgi प्रोटोकॉल का उपयोग करेगा। uWSGI से बात करें, और इसलिए, हाँ, प्रसंस्करण में बहुत कम दोहराव शामिल है।

— क्रॉमी

यह एक अच्छा जवाब है, हालांकि, इस विषय पर uWSGI के स्वयं के दस्तावेज़ के लिंक के साथ इसे बेहतर बनाया जा सकता है, जो अधिक विवरण के साथ बताता है कि आप uWSGI के साथ क्या कर सकते हैं: uwsgi-docs.readthedocs.io/en/latest/…

— टोबियास McNulty

Answer 2

IMO, यदि आप अपनी वेबसाइट को Lab की जगह Internet में रखते हैं, तो आपको अंतर दिखाई दे सकता है।

अपनी वेबसाइट तक पहुंचने के लिए कम नेटवर्क गति वाले खुले वेब ब्राउज़र वाले किसी अन्य देश के उपयोगकर्ता की कल्पना करें। uWSGI उस Http कनेक्शन को एक थ्रेड में संभालेगा। कम नेटवर्क गति के कारण पूर्ण Http अनुरोध के लिए प्रतीक्षा करने के लिए वह धागा बहुत लंबा समय बिता सकता है। यदि आपके थ्रेड पूल का आकार 100 है, तो 100 उपयोगकर्ताओं को इस तरह की धीमी गति से कल्पना करें कि क्या होगा? अन्य Http अनुरोध को संभालने के लिए कोई निष्क्रिय धागा नहीं।

लेकिन नग्नेक्स के लिए चीजें काफी अलग हैं। Nginx को 'रिएक्टर पैटर्न' में डिज़ाइन किया गया है। आप Google 'रिएक्टर पैटर्न' को देख सकते हैं कि यह कैसे काम करता है। संक्षेप में, धीमी गति कनेक्शन अन्य Http अनुरोधों को संभालने के लिए इसे प्रभावित नहीं करता है।

Comments

मुझे संदेह है कि Nginx का उपयोग करने वाला है जो बदलने जा रहा है। जब WSGI का उपयोग करके अपाचे पर एक Django एप्लिकेशन को होस्ट किया जाता है, तो किसी सॉकेट से किसी भी POST डेटा को पढ़ने से पहले व्यू फ़ंक्शन को कॉल किया जाएगा। इसलिए यदि क्लाइंट धीमा है, तो यह अनुरोध से एक थ्रेड पर कब्जा कर लेगा, जब तक कि POST डेटा प्राप्त नहीं हुआ है। नगीने के साथ अपाचे की जगह क्यों बदलेगी?

— कैस्परर्ड

जैसा कि मुझे पता है, डिफ़ॉल्ट रूप से, निग्नेक्स HTTP सर्वर को बैकडेट करने का अनुरोध नहीं करेगा, जब तक कि उसे पूर्ण HTTP अनुरोध नहीं मिलता। तो Django जैसे एप्लिकेशनटोन सर्वर के लिए, जो उन्हें मिला है वह हमेशा एक तेज़ HTTP कंसेशन और रिक्वेस्ट है, कोई भी समय पूरा http अनुरोध के इंतजार में व्यर्थ नहीं जाता है, जल्द ही खोज को संभालने के बाद, जल्द ही अगले एचटीटीपी अनुरोध के लिए रनिंग थ्रेड निष्क्रिय हो सकता है।

— Jcyrss

इसे अनुरोध बफ़रिंग कहा जाता है, जो Nginx में डिफ़ॉल्ट रूप से सक्षम है (Nginx के पुराने संस्करणों में इसे बंद करना संभव नहीं था): nginx.org/en/docs/http/…

— Tobias