पर कैसे पहुंचाता है किसी भी वेब सर्वर को एक ही समय में कई अनुरोधों को संभालना पड़ सकता है। चूंकि पाइथन दुभाषिया वास्तव में जीआईएल बाधा है, कैसे समेकन लागू किया जाता है?एक पाइथन वेब सर्वर जीआईएल
क्या वे कई प्रक्रियाओं का उपयोग करते हैं और राज्य साझाकरण के लिए आईपीसी का उपयोग करते हैं?
सामान्य के रूप में। वेब सेवारत ज्यादातर I/O-bound है, और जीआईएल I/O संचालन के दौरान जारी किया जाता है। तो या तो थ्रेडिंग किसी भी विशेष आवास के बिना प्रयोग किया जाता है, या एक घटना लूप (जैसे ट्विस्टेड) का उपयोग किया जाता है।
मैं प्रतीक्षा/प्राप्त अनुरोध के बारे में बात नहीं कर रहा हूं। मैं उन्हें संभालने के बारे में बात कर रहा हूं। उदाहरण के लिए, अगर मुझे कोई अनुरोध प्राप्त होता है, तो मुझे कुछ प्रोसेसिंग करना पड़ सकता है, जैसे कि विभिन्न पोस्ट या जीईटी अनुरोधों की जांच करना, जिसे आमतौर पर पाइथन कोड के रूप में लिखा जाता है। तो पाइथन दुभाषिया कोड के इन ब्लॉक को एक साथ कैसे निष्पादित करेगा क्योंकि इसमें जीआईएल बाधा है। –
यह बस असत्य है। सभी वर्कलोड IO बाध्य नहीं हैं I अधिकतम सर्वरों के साथ वेब सर्वर देखने के लिए यह पूरी तरह से आम है। यह चल रहे आवेदन पर निर्भर करता है। – usr
आपके पास आमतौर पर कई कर्मचारी होते हैं (यानी गनिकोर्न), प्रत्येक को स्वतंत्र अनुरोधों के साथ भेजा जा रहा है। बाकी सब कुछ (समवर्ती संबंधित) डेटाबेस द्वारा संभाला जाता है, इसलिए यह आपके द्वारा सारणीबद्ध है।
आप आईपीसी की जरूरत नहीं है, तो आप सिर्फ एक "सच्चाई का एकल स्रोत" है, जो आरडीबीएमएस, एक कैश सर्वर (redis, memcached) हो जाएगा, आदि
सबसे पहले जरूरत है, अनुरोध किया जा सकता है स्वतंत्र रूप से संभाला। हालांकि, सर्वर एक साथ उन अनुरोधों की संख्या को बनाए रखने के लिए संभालते हैं जिन्हें अधिकतम समय पर संभाला जा सकता है।
समेकन की इस अवधारणा के कार्यान्वयन वेबसर्वर पर निर्भर करता है।
कुछ कार्यान्वयन में अनुरोधों को संभालने के लिए थ्रेड या प्रक्रियाओं की एक निश्चित संख्या हो सकती है। यदि सभी उपयोग में हैं, तो अतिरिक्त अनुरोधों को संभालने तक इंतजार करना होगा।
एक और संभावना यह है कि प्रत्येक अनुरोध के लिए एक प्रक्रिया या धागा पैदा होता है। प्रत्येक अनुरोध के लिए एक प्रक्रिया को जन्म देने से एक बेतुका स्मृति और सीपीयू ओवरहेड होता है। हल्के धागे की चमक बेहतर है। ऐसा करने से, आप प्रति सेकंड सैकड़ों ग्राहकों की सेवा कर सकते हैं। हालांकि, धागे भी अपने प्रबंधन को ऊपर की ओर लाते हैं, जो खुद को उच्च स्मृति और सीपीयू खपत में प्रकट करते हैं।
प्रति सेकेंड हजारों ग्राहकों की सेवा के लिए, एसिंक्रोनस कोरआउटिन पर आधारित एक ईवेंट-संचालित आर्किटेक्चर एक अत्याधुनिक समाधान है। यह सर्वर को थ्रेड के ज़िलियन के बिना उच्च दर पर ग्राहकों की सेवा करने में सक्षम बनाता है। Wikipedia page of the so-called C10k problem पर आपको वेब सर्वर की एक सूची मिलती है। उनमें से कई लोग इस वास्तुकला का उपयोग करते हैं।
कोरियटिन भी पाइथन के लिए उपलब्ध हैं। http://www.gevent.org/ पर देखें। यही कारण है कि uWSGI + गीवेंट पर आधारित एक पायथन डब्लूएसजीआई ऐप एक बेहद सक्षम समाधान है।
"प्रत्येक अनुरोध के लिए एक प्रक्रिया को फैलाने से एक बेतुका स्मृति और सीपीयू ओवरहेड होता है।" यह ओएस पर पूरी तरह से निर्भर है। –
@ IgnacioVazquez-Abrams: जिसके लिए ओएस यह सच नहीं है ("बेतुका" थ्रेडिंग या कोरआउट के ऊपरी हिस्से की तुलना में था)? –
ऐसा नहीं है कि यह सच नहीं है, यह है कि "बेतुका" की सटीक परिभाषा भिन्न होती है; जब नई प्रक्रियाएं शुरू करने की बात आती है तो विंडोज आशीर्वाद विसर्जन का एक बड़ा स्टीमिंग ढेर है, लेकिन * तुलना में नाइस काफी हल्का होता है। –
क्या राज्य साझा करना? वेब अनुरोधों का पूरा बिंदु यह है कि प्रत्येक स्वतंत्र है, कोई साझा स्थिति नहीं है। –