हम सभी ने बेंचमार्क पढ़े हैं और तथ्यों को जानते हैं - ईवेंट-आधारित एसिंक्रोनस नेटवर्क सर्वर उनके थ्रेडेड समकक्षों की तुलना में तेज़ हैं। Lighttpd या ज़ीउस बनाम अपाचे या आईआईएस सोचो। ऐसा क्यों है?इवेंट-आधारित नेटवर्क अनुप्रयोग थ्रेड वाले लोगों की तुलना में स्वाभाविक रूप से तेज़ क्यों हैं?
मुझे लगता है कि घटना आधारित बनाम थ्रेड आधारित सवाल नहीं है - यह एक गैर-अवरुद्ध मल्टीप्लेक्ड I/O, चयन करने योग्य सॉकेट, समाधान बनाम थ्रेड पूल समाधान है।
पहले मामले में आप जो भी उपयोग कर रहे हैं उसके बावजूद सभी इनपुट को संभालने में कामयाब रहे हैं- इसलिए पढ़ने पर कोई अवरोध नहीं है- एक 'श्रोता'। एकल श्रोता धागा प्रत्येक कनेक्शन के लिए एक के बजाय डेटा को अलग-अलग प्रकार के कार्यकर्ता धागे के रूप में पास कर सकता है। दोबारा, किसी भी डेटा को लिखने पर कोई अवरोध नहीं - इसलिए डेटा हैंडलर इसके साथ अलग-अलग चला सकता है। चूंकि यह समाधान ज्यादातर आईओ पढ़ता/लिखता है, यह बहुत सी CPU समय पर कब्जा नहीं करता है- इस प्रकार आपका आवेदन वह जो कुछ भी चाहता है उसे करने के लिए ले सकता है।
थ्रेड पूल समाधान में आपके पास प्रत्येक कनेक्शन को संभालने वाले व्यक्तिगत धागे होते हैं, इसलिए उन्हें संदर्भ स्विच में समय और बाहर साझा करना होता है- प्रत्येक 'सुनना'। इस समाधान में सीपीयू + आईओ ओप एक ही धागे में होते हैं- जो एक समय टुकड़ा हो जाता है- इसलिए आप प्रति थ्रेड (अवरुद्ध) को पूरा करने के लिए आईओ ओप पर इंतजार कर रहे हैं जो परंपरागत रूप से CPU समय का उपयोग किए बिना किया जा सकता है।
गैर-अवरुद्ध आईओ के लिए Google अधिक जानकारी के लिए- और आप कुछ तुलना बनाम थ्रेड पूल भी ढूंढ सकते हैं।
(यदि किसी को भी इन बिंदुओं को स्पष्ट कर सकते हैं, के लिए स्वतंत्र महसूस)
यह वास्तव में धागे के बारे में नहीं है। यह सेवा अनुरोधों के लिए धागे का उपयोग करने के तरीके के बारे में है। Lighttpd जैसे कुछ के लिए आपके पास एक सिंगल थ्रेड है जो ईवेंट के माध्यम से कई कनेक्शन सेवाएं प्रदान करता है। अपाचे के पुराने संस्करणों के लिए आपके पास प्रति कनेक्शन एक प्रक्रिया थी और प्रक्रिया आने वाले डेटा पर जाग गई थी, इसलिए बहुत सारे अनुरोध होने पर आप बहुत बड़ी संख्या में समाप्त हुए। हालांकि एमपीएम अपाचे के साथ घटना आधारित है और साथ ही apache MPM event देखें।
यह वास्तव में निर्भर करता है कि आप क्या कर रहे हैं; घटना-आधारित प्रोग्रामिंग अनिवार्य अनुप्रयोगों के लिए निश्चित रूप से मुश्किल है। एक वेब सर्वर होने के नाते वास्तव में एक बहुत ही मामूली अच्छी तरह से समझी गई समस्या है और दोनों घटना संचालित और थ्रेडेड मॉडल आधुनिक ओएस पर बहुत अच्छी तरह से काम करते हैं।
एक घटना मॉडल में अधिक जटिल सर्वर अनुप्रयोगों को सही ढंग से विकसित करना आम तौर पर बहुत मुश्किल है - थ्रेडेड अनुप्रयोग लिखना बहुत आसान है। यह प्रदर्शन के बजाय निर्णायक कारक हो सकता है।
इवेंट-संचालित अनुप्रयोग स्वाभाविक रूप से तेज़ नहीं हैं।
Why Events Are a Bad Idea (for High-Concurrency Servers) से:
We examine the claimed strengths of events over threads and show that the
weaknesses of threads are artifacts of specific threading implementations
and not inherent to the threading paradigm. As evidence, we present a
user-level thread package that scales to 100,000 threads and achieves
excellent performance in a web server.
यह 2003 निश्चित रूप से आधुनिक OS के पर सूत्रण के राज्य तब से सुधार हुआ है में था।
किसी इवेंट-आधारित सर्वर के मूल को लिखने का अर्थ है आपके कोड में सहकारी मल्टीटास्किंग (विंडोज 3.1 स्टाइल) का पुन: आविष्कार करना, संभवतया एक ओएस पर जो पहले से ही पूर्व पूर्व-खाली मल्टीटास्किंग का समर्थन करता है, और पारदर्शी संदर्भ स्विचिंग के लाभ के बिना । इसका मतलब है कि आपको ढेर पर राज्य का प्रबंधन करना होगा जो आमतौर पर निर्देश सूचक द्वारा निहित किया जाएगा या एक स्टैक चर में संग्रहीत किया जाएगा। (यदि आपकी भाषा में उन्हें बंद कर दिया गया है, तो बंदरगाह इस दर्द को काफी कम करता है। सी में ऐसा करने की कोशिश करना बहुत कम मजेदार है।)
इसका मतलब यह भी है कि आप सभी चेतावनी सहकारी मल्टीटास्किंग का तात्पर्य प्राप्त करते हैं।यदि किसी भी ईवेंट के हैंडलर को किसी भी कारण से चलाने में कुछ समय लगता है, तो यह उस ईवेंट थ्रेड को स्टाल करता है। पूरी तरह से असंबंधित अनुरोध अंतराल। यहां तक कि लंबे समय तक सीपीयू-इनवेसिव ऑपरेशंस को इससे बचने के लिए कहीं और भेजा जाना है। जब आप एक उच्च-समवर्ती सर्वर के मूल के बारे में बात कर रहे हैं, तो 'लंबा ऑपरेशन' प्रति सेकंड 100,000 अनुरोधों को संभालने की अपेक्षा रखने वाले सर्वर के लिए माइक्रोसेकंड के क्रम पर एक सापेक्ष शब्द होता है। मुझे आशा है कि वर्चुअल मेमोरी सिस्टम को आपके लिए डिस्क से पेज खींचना पड़ेगा!
किसी ईवेंट-आधारित आर्किटेक्चर से अच्छा प्रदर्शन प्राप्त करना मुश्किल हो सकता है, खासकर जब आप विलंबता पर विचार करते हैं और केवल थ्रूपुट नहीं करते हैं। (बेशक, वहाँ गलतियों के बहुत सारे आप रूप में अच्छी तरह धागे से बना सकते हैं कन्करेंसी अभी भी कठिन है।।) एक नया सर्वर अनुप्रयोग के लेखक के लिए
एक जोड़े को महत्वपूर्ण सवाल:
प्रतिक्रिया के लिए धन्यवाद। – dowski