खुलने वाले विचार
आप इस निष्कर्ष पर कैसे पहुंचे कि सिस्टम के कुछ हिस्से दूसरी भाषा में बेहतर तरीके से फ़ेयर होंगे? क्या आप प्रदर्शन समस्याओं से पीड़ित हैं? वे समस्याएं कितनी गंभीर हैं? यदि यह तेज हो सकता है, तो क्या यह जरूरी है कि यह तेज हो?
एकल-धागा अतुल्यकालिक
कई प्रश्न और अन्य वेब संसाधन हैं जो पहले से ही एकल-धागा अतुल्यकालिक बनाम बहु-सूत्रीय समरूपता के अंतर, पेशेवरों और विपक्षों से निपटते हैं। जब I / O प्रमुख अड़चन है, तो Node.js का सिंगल-थ्रेड एसिंक्रोनस मॉडल कैसे प्रदर्शन करता है, इसके बारे में पढ़ना दिलचस्प है और एक ही बार में कई अनुरोध किए जा रहे हैं।
मुड़, बवंडर और अन्य अतुल्यकालिक मॉडल एकल-धागे का उत्कृष्ट उपयोग करते हैं। चूंकि बहुत सारे वेब प्रोग्रामिंग में बहुत सारे I / O (नेटवर्क, डेटाबेस, आदि) हैं, इसलिए दूरस्थ कॉल पर प्रतीक्षा करने में लगने वाला समय काफी बढ़ जाता है। वह समय जो अन्य चीजों को करने में खर्च किया जा सकता है - जैसे अन्य डेटाबेस कॉल को बंद करना, पृष्ठों को रेंडर करना और डेटा उत्पन्न करना। उस एकल-सूत्र का उपयोग बहुत अधिक है।
एकल-धागा अतुल्यकालिक के सबसे बड़े लाभों में से एक यह है कि यह उपयोग करता है बहुत कम मेमोरी है । बहु-थ्रेड निष्पादन में, प्रत्येक थ्रेड को एक निश्चित मात्रा में आरक्षित मेमोरी की आवश्यकता होती है। चूंकि थ्रेड्स की संख्या बढ़ जाती है, इसलिए थ्रेड्स की मौजूदगी के लिए मेमोरी की मात्रा आवश्यक है। चूंकि मेमोरी परिमित है, इसका मतलब है कि थ्रेड्स की संख्या पर सीमाएं हैं जो किसी भी समय बनाई जा सकती हैं।
उदाहरण
एक वेब सर्वर के मामले में, प्रत्येक अनुरोध का ढोंग अपने स्वयं के धागे से किया जाता है। कहें कि प्रत्येक थ्रेड के लिए 1MB मेमोरी आवश्यक है, और वेब सर्वर में 2GB RAM है। यह वेब सर्वर किसी भी समय किसी भी बिंदु पर प्रसंस्करण (लगभग) 2000 अनुरोधों को सक्षम करने में सक्षम होगा, इससे पहले कि किसी भी अधिक प्रक्रिया के लिए पर्याप्त मेमोरी न हो।
यदि आपका लोड इससे काफी अधिक है, तो अनुरोधों को बहुत लंबा समय लगने वाला है (जब पुराने अनुरोधों के पूरा होने की प्रतीक्षा है), या आप समवर्ती अनुरोधों की संख्या का विस्तार करने के लिए क्लस्टर में अधिक सर्वर फेंकने जा रहे हैं। ।
मल्टी-थ्रेड कॉनकरी
मल्टी-थ्रेड कॉन्सेप्ट इसके बजाय एक ही समय में कई कार्यों को निष्पादित करने पर निर्भर करता है। इसका मतलब है कि यदि एक थ्रेड को डेटाबेस कॉल पर लौटने के इंतजार में अवरुद्ध किया जाता है, तो अन्य अनुरोधों को उसी समय संसाधित किया जा सकता है। थ्रेड का उपयोग कम है, लेकिन थ्रेड निष्पादन की संख्या बहुत बड़ी है।
बहु-धागा कोड के बारे में तर्क करना भी बहुत कठिन है। लॉकिंग, सिंक्रोनाइज़ेशन, और अन्य मज़ेदार संगामिति समस्याओं के साथ समस्याएँ हैं। एकल-धागा अतुल्यकालिक समान समस्याओं से ग्रस्त नहीं है।
मल्टी-थ्रेड कोड सीपीयू इंटेंसिव के लिए बहुत अधिक परफॉर्मेंट है हालांकि कार्यों के । यदि एक थ्रेड के लिए "यील्ड" के लिए कोई अवसर मौजूद नहीं है, तो एक नेटवर्क कॉल के रूप में, जो सामान्य रूप से एक सिंगल-थ्रेड मॉडल को ब्लॉक करेगा - जो कि किसी भी संगामिति के लिए नहीं होगा।
दोनों मई कोएक्सिस्ट
बेशक दोनों के बीच ओवरलैप है; वे पारस्परिक रूप से विशिष्ट नहीं हैं। उदाहरण के लिए, प्रत्येक थ्रेड का बेहतर उपयोग करने के लिए, मल्टी-थ्रेड कोड को गैर-अवरुद्ध तरीके से लिखा जा सकता है।
तल - रेखा
विचार करने के लिए कई अन्य मुद्दे हैं, लेकिन मुझे इस तरह से दो के बारे में सोचना पसंद है:
- यदि आपका कार्यक्रम I / O बाध्य है , तो एकल-धागा अतुल्यकालिक संभवतः काफी अच्छा काम करने वाला है।
- यदि आपका प्रोग्राम सीपीयू बाउंड है , तो बहु-थ्रेड सिस्टम शायद सबसे अच्छा होगा।
आपके विशेष मामले में, आपको यह निर्धारित करने की आवश्यकता है कि किस प्रकार का अतुल्यकालिक काम पूरा हो रहा है, और कितनी बार उन कार्यों का उदय होता है।
- क्या वे हर अनुरोध पर होते हैं? यदि हां, तो मेमोरी शायद एक मुद्दा बनने जा रही है क्योंकि अनुरोधों की संख्या बढ़ जाती है।
- क्या ये कार्य आदेशित हैं? यदि ऐसा है, तो आपको कई थ्रेड्स का उपयोग करके सिंक्रनाइज़ेशन पर विचार करना होगा।
- क्या ये कार्य सीपीयू गहन हैं? यदि हां, तो क्या एक एकल धागा लोड के साथ बनाए रखने में सक्षम है?
कोई सरल जवाब नहीं है। आपको इस बात पर विचार करना चाहिए कि आपके उपयोग के मामले क्या हैं, और तदनुसार डिजाइन करें। कभी-कभी एक अतुल्यकालिक एकल-धागा मॉडल बेहतर होता है। दूसरी बार, बड़े पैमाने पर समानांतर प्रसंस्करण को प्राप्त करने के लिए कई थ्रेड्स का उपयोग करना आवश्यक है।
अन्य बातें
ऐसे अन्य मुद्दे हैं जिन पर आपको विचार करने की ज़रूरत है, बजाय इसके कि आपके द्वारा चुने गए समरूप मॉडल के बजाय। क्या आप एरलांग या क्लोजर जानते हैं? क्या आपको लगता है कि आप इनमें से किसी एक भाषा में सुरक्षित मल्टी-थ्रेड कोड लिखने में सक्षम होंगे, जिससे आप अपने आवेदन के प्रदर्शन में सुधार कर सकते हैं? क्या इन भाषाओं में से किसी एक में तेजी लाने के लिए एक लंबा समय लगने वाला है, और क्या आप जो भाषा सीखते हैं, वह आपको भविष्य में फायदा पहुंचाएगा?
इन दो प्रणालियों के बीच संचार से जुड़ी कठिनाइयों के बारे में कैसे? क्या यह समानांतर रूप से दो अलग-अलग प्रणालियों को बनाए रखने में जटिल होगा? एर्लांग प्रणाली को Django से कार्य कैसे प्राप्त होंगे? Erlang उन परिणामों को Django पर वापस कैसे संचारित करेगा? क्या प्रदर्शन महत्वपूर्ण एक समस्या है जो अतिरिक्त जटिलता इसके लायक है?
अंतिम विचार
मैंने हमेशा Django को काफी जल्दी पाया है, और यह कुछ बहुत भारी ट्रैफ़िक साइटों द्वारा उपयोग किया जाता है। कई प्रदर्शन अनुकूलन हैं जो आप समवर्ती अनुरोधों और प्रतिक्रिया समय की संख्या बढ़ाने के लिए कर सकते हैं। बेशक, मैंने सेलेरी के साथ अब तक कुछ भी नहीं किया है, इसलिए सामान्य प्रदर्शन अनुकूलन शायद आपके द्वारा इन अतुल्यकालिक कार्यों के साथ होने वाले किसी भी मुद्दे को हल करने के लिए नहीं जा रहे हैं।
बेशक, हमेशा समस्या पर अधिक हार्डवेयर फेंकने का सुझाव है। क्या एक नए सर्वर के प्रावधान की लागत विकास और रखरखाव की तुलना में पूरी तरह से नए उपतंत्र से सस्ती है?
मैंने इस बिंदु पर बहुत सारे सवाल पूछे हैं, लेकिन यह मेरा इरादा था। विश्लेषण और आगे के विवरण के बिना उत्तर आसान नहीं होगा। समस्याओं का विश्लेषण करने में सक्षम होने के कारण प्रश्नों को जानने के लिए नीचे आता है, हालांकि ... उम्मीद है कि मैंने उस मोर्चे पर मदद की है।
मेरी आंत की भावना कहती है कि किसी अन्य भाषा में फिर से लिखना अनावश्यक है। जटिलता और लागत शायद बहुत शानदार होगी।
संपादित करें
अनुवर्ती कार्रवाई करने के लिए प्रतिक्रिया
आपका अनुवर्ती कुछ बहुत ही रोचक उपयोग के मामले प्रस्तुत करता है।
1. HTTP अनुरोध के बाहर काम कर रहे Django
आपके पहले उदाहरण में NFC टैग पढ़ना, फिर डेटाबेस को क्वेरी करना शामिल था। मुझे नहीं लगता कि इस भाग को किसी अन्य भाषा में लिखना आपके लिए उपयोगी होगा, क्योंकि डेटाबेस या LDAP सर्वर को क्वेरी करना नेटवर्क I / O (और संभावित डेटाबेस प्रदर्शन) से बाध्य होने वाला है। दूसरी ओर, समवर्ती अनुरोधों की संख्या स्वयं सर्वर द्वारा बाध्य होगी, क्योंकि प्रत्येक प्रबंधन कमांड को अपनी प्रक्रिया के रूप में चलाया जाएगा। सेटअप और टियरडाउन समय होगा जो प्रदर्शन को प्रभावित करता है, क्योंकि आप पहले से चल रहे प्रक्रिया को संदेश नहीं भेज रहे हैं। हालांकि, आप एक ही समय में कई अनुरोध भेजने में सक्षम होंगे, क्योंकि प्रत्येक एक अलग प्रक्रिया होगी।
इस मामले के लिए, मुझे दो रास्ते दिखाई दे रहे हैं जिनकी आप जाँच कर सकते हैं:
- सुनिश्चित करें कि आपका डेटाबेस कनेक्शन पूलिंग के साथ एक साथ कई प्रश्नों को संभालने में सक्षम है। (उदाहरण के लिए, Oracle के लिए आवश्यक है कि आप तदनुसार Django कॉन्फ़िगर करें
'OPTIONS': {'threaded':True}।) डेटाबेस स्तर या Django स्तर पर समान कॉन्फ़िगरेशन विकल्प हो सकते हैं जिन्हें आप अपने डेटाबेस के लिए ट्वीक कर सकते हैं। इससे कोई फर्क नहीं पड़ता कि आप अपने डेटाबेस के प्रश्नों को किस भाषा में लिखते हैं, आपको एल ई डी को लाइट करने से पहले इस डेटा के वापस आने का इंतजार करना होगा। क्वेरी कोड के प्रदर्शन से फर्क पड़ सकता है , और Django ORM तेजी से बिजली नहीं मार रहा है ( लेकिन , आमतौर पर पर्याप्त तेजी से)।
- सेटअप / आंसू समय कम करें। लगातार चलने वाली प्रक्रिया है, और इसे संदेश भेजें। (सही होने पर मुझे सही करें, लेकिन यह वही है जो आपका मूल प्रश्न वास्तव में है।) क्या यह प्रक्रिया पायथन / Django या किसी अन्य भाषा / रूपरेखा में लिखी गई है या नहीं। मुझे इतनी बार प्रबंधन आदेशों का उपयोग करने का विचार पसंद नहीं आया। क्या यह संभव है कि कोड का एक छोटा सा टुकड़ा लगातार चल रहा हो, जो एनएफसी पाठकों के संदेशों को संदेश कतार पर धकेलता है, जिसे सेलेरी फिर पढ़ता है और आगे से Django? एक छोटे से कार्यक्रम की स्थापना और फाड़, भले ही यह पायथन में लिखा गया हो (लेकिन Django!), Django कार्यक्रम को शुरू करने और रोकने के लिए बेहतर नहीं होना चाहिए (इसके सभी उपतंत्रों के साथ)।
मैं अनिश्चित हूं कि आप Django के लिए किस वेब सर्वर का उपयोग कर रहे हैं। mod_wsgiअपाचे के लिए आप उन प्रक्रियाओं की संख्या और थ्रेड को कॉन्फ़िगर कर सकते हैं जो सेवा अनुरोधों की प्रक्रियाओं के भीतर हैं। ध्यान देने योग्य अनुरोधों की संख्या का अनुकूलन करने के लिए अपने वेब सर्वर के प्रासंगिक कॉन्फ़िगरेशन को ट्विस्ट करना सुनिश्चित करें।
2. "मैसेज-पासिंग" Django सिग्नल के साथ
आपका दूसरा उपयोग मामला भी काफी दिलचस्प है; मुझे यकीन नहीं है कि अगर मेरे पास इसके लिए उत्तर हैं। यदि आप मॉडल इंस्टेंसेस को हटा रहे हैं, और बाद में उन पर काम करना चाहते हैं, JSON.dumpsतो उन्हें क्रमबद्ध करना और फिर डीरियलाइज़ करना संभव हो सकता है JSON.loads। डेटाबेस से संबंधित फ़ील्ड को लोड किए जाने के बाद से ऑब्जेक्ट से संबंधित ऑब्जेक्ट (बाद में संबंधित मॉडल) को पूरी तरह से फिर से बनाना असंभव होगा, और यह लिंक अब मौजूद नहीं होगा।
अन्य विकल्प यह होगा कि किसी तरह विलोपन के लिए एक वस्तु को चिह्नित किया जाए , और केवल अनुरोध / प्रतिक्रिया चक्र के अंत में इसे हटा दें (सभी संकेतों के बाद सेवा की गई है)। इसे लागू करने के बजाय इसे लागू करने के लिए कस्टम सिग्नल की आवश्यकता हो सकती है post_delete।