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


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

लेकिन मुझे इस किट में nginx क्यों चाहिए? uWSGI स्वयं डब्लूएसजीआई पायथन अनुप्रयोगों की सेवा कर सकता है, यह स्थैतिक फाइलों की सेवा कर सकता है, यह एसएसएल भी कर सकता है। Nginx क्या कर सकता है जो uWSGI नहीं कर सकता?


52
2018-04-23 14:44


मूल


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


जवाब:


आप नहीं करते

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

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

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

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

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


47
2018-04-23 15:25



एक बात जो दिमाग में आती है, मुझे लगता है कि आपके उत्तर में शामिल @ क्रोमी के अलावा यह ध्यान देने योग्य है कि यूडब्ल्यूएसजीआई के लिए मूल प्रोटोकॉल http नहीं है लेकिन यूवीजीआई प्रोटोकॉल है। Uwsgi प्रोटोकॉल http से निपटने के लिए सरल और अधिक कुशल है और इस प्रकार आपके यूडब्ल्यूएसजीआई एप्लिकेशन के सामने एक अधिक पूर्ण-विशेषीकृत वेब सर्वर (nginx या whatnot) चिपकाना वास्तव में बहुत अधिक प्रसंस्करण को डुप्लिकेट नहीं करता है और आपके आधार पर महत्वपूर्ण लाभ प्रदान कर सकता है की जरूरत है। - Håkan Lindqvist
@ हकनलिंडक्विस्ट बिल्कुल सही है; बस स्पष्ट करने के लिए, यूडब्ल्यूएसजीआई HTTP बोलने में पूरी तरह से सक्षम है, हालांकि, अपने आप ठीक से खड़े हो सकते हैं, लेकिन हां यह ध्यान देने योग्य है कि इसके सामने एक वेब सर्वर यूवीजीआई प्रोटोकॉल का उपयोग करेगा, HTTP नहीं, यूडब्ल्यूएसजीआई से बात करें, और इसलिए, हाँ, प्रसंस्करण के बहुत कम नकल शामिल हैं। - Kromey
यह एक अच्छा जवाब है, हालांकि, इस विषय पर यूडब्ल्यूएसजीआई के अपने दस्तावेज के लिंक के साथ इसे बेहतर किया जा सकता है, जो बताता है कि आप क्या निर्दिष्ट करते हैं कर सकते हैं uWSGI के साथ करें: uwsgi-docs.readthedocs.io/en/latest/... - Tobias McNulty


आईएमओ, यदि आप लैब के बजाय अपनी वेबसाइट इंटरनेट पर डालते हैं, तो आप अंतर देख सकते हैं।

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

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


1
2018-05-26 09:45



मुझे संदेह है कि Nginx का उपयोग करने जा रहा है। जब डब्लूएसजीआई का उपयोग करते हुए अपाचे पर एक Django एप्लिकेशन होस्ट किया जाता है, तो किसी भी पोस्ट डेटा को सॉकेट से पढ़ने से पहले दृश्य फ़ंक्शन को कॉल किया जाएगा। तो यदि ग्राहक धीमा है, तो अनुरोध डेटा प्राप्त होने तक अनुरोध से एक थ्रेड प्राप्त होगा। Nginx के साथ अपाचे को बदलना क्यों बदलेगा? - kasperd
जैसा कि मुझे पता है, डिफ़ॉल्ट रूप से, Nginx पूर्ण HTTP अनुरोध प्राप्त होने तक एप्लिकेशन सर्वर को बैकएंड करने के लिए HTTP अनुरोध प्रॉक्सी नहीं करेगा। तो Django जैसे आवेदक सर्वर के लिए, उन्हें जो भी मिला वह हमेशा एक तेज़ HTTP संवेदना और अनुरोध है, जल्द ही खोज को संभालने के बाद, पूर्ण http अनुरोध की प्रतीक्षा करने पर कोई समय बर्बाद नहीं हुआ, चलने वाला थ्रेड जल्द ही अगले एचटीपी अनुरोध के लिए निष्क्रिय हो सकता है। - jcyrss
इसे अनुरोध बफरिंग कहा जाता है, जिसे डिफ़ॉल्ट रूप से Nginx में सक्षम किया जाता है (Nginx के पुराने संस्करणों में इसे बंद करना संभव नहीं था): nginx.org/en/docs/http/... - Tobias McNulty