क्या प्रति अनुरोध मॉडल थ्रेड गैर-अवरुद्ध I/O से तेज हो सकता है?

Question

मैं जहां लोगों को दावा किया है कि आधुनिक सूत्रण पुस्तकालयों इतना अच्छा है कि धागा प्रति अनुरोध सर्वर केवल गैर अवरुद्ध सर्वर से लिखना आसान नहीं होगा मिल रहे थे याद 2 या 3 साल पहले पढ़ने एक जोड़े लेख लेकिन यह है कि वे तेजी से हो जाएगा भी मेरा मानना ​​है कि यह जावा में एक जेवीएम के साथ भी प्रदर्शित किया गया था जिसने जावा थ्रेड को पैथ्रेड में मैप किया था (यानी जावा एनओ ओवरहेड संदर्भ-स्विचिंग ओवरहेड से अधिक था)।

लेकिन अब मैं सभी "अत्याधुनिक" सर्वर अतुल्यकालिक पुस्तकालयों का उपयोग देखना (जावा NIO, epoll, यहां तक ​​कि Node.js)। क्या इसका मतलब है कि एसिंक जीता?

Answer 1

मेरी राय में नहीं। यदि दोनों मॉडल अच्छी तरह लागू होते हैं (यह एक बड़ी आवश्यकता है) मुझे लगता है कि एनआईओ की अवधारणा को जीतना चाहिए।

कंप्यूटर के दिल में कोर हैं। कोई फर्क नहीं पड़ता कि आप क्या करते हैं, आप कोर के मुकाबले अपने आवेदन को समानांतर नहीं कर सकते हैं। यानी यदि आपके पास 4 कोर मशीन है, तो आप केवल एक ही समय में 4 चीजें कर सकते हैं (मैं यहां कुछ विवरणों पर चमक रहा हूं, लेकिन यह तर्क के लिए पर्याप्त है)।

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

आदर्श रूप से, आपके पास कोर प्रति सिंगल थ्रेड है, और उनमें से प्रत्येक थ्रेड अपने मूल पर 100% प्रोसेसिंग गति पर चल रहा है। आदर्श में कार्य स्विचिंग नहीं होगी। बेशक ओएस है, लेकिन यदि आप 16 कोर मशीन लेते हैं और ओएस के लिए 2-3 धागे छोड़ देते हैं, तो शेष 13-14 आपके ऐप की ओर जाते हैं। वे धागे के भीतर अपने ऐप को स्विच कर सकते हैं, जैसे कि जब वे आईओ आवश्यकताओं से अवरुद्ध होते हैं, लेकिन ओएस स्तर पर उस लागत का भुगतान नहीं करना पड़ता है। इसे अपने ऐप में लिखें।

इस स्केलिंग का एक उत्कृष्ट उदाहरण SEDA http://www.eecs.harvard.edu/~mdw/proj/seda/ में देखा जाता है। यह मानक थ्रेड-प्रति-अनुरोध मॉडल की तुलना में लोड के तहत बहुत बेहतर स्केलिंग दिखाता है।

मेरा व्यक्तिगत अनुभव नेटटी के साथ है। मेरे पास एक साधारण ऐप था। मैंने इसे टॉमकैट और नेटटी दोनों में अच्छी तरह कार्यान्वित किया। फिर मैंने इसे 100 के समवर्ती अनुरोधों के साथ परीक्षण किया (800 से ऊपर मुझे विश्वास है)। आखिरकार टोमकैट ने एक क्रॉल में धीमा कर दिया और बेहद विस्फोट/लगी व्यवहार का प्रदर्शन किया। जबकि नेटटी कार्यान्वयन ने प्रतिक्रिया समय में वृद्धि की, लेकिन अविश्वसनीय रूप से समग्र थ्रूपुट के साथ जारी रखा।

कृपया ध्यान दें, यह ठोस कार्यान्वयन पर निर्भर करता है। समय के साथ एनआईओ अभी भी बेहतर हो रहा है। हम सीख रहे हैं कि हमारे सर्वर ओएस को बेहतर तरीके से काम करने के साथ-साथ ओएस कार्यक्षमता को बेहतर लाभ उठाने के लिए जेवीएम को कैसे कार्यान्वित किया जाए। मुझे नहीं लगता कि विजेता को अभी तक घोषित किया जा सकता है, लेकिन मेरा मानना ​​है कि एनआईओ अंतिम विजेता होगा, और यह पहले से ही काफी अच्छा कर रहा है।

Answer 2

यह तब तक तेज़ है जब तक पर्याप्त स्मृति हो।

जब वहाँ बहुत अधिक कनेक्शन, जिनमें से अधिकांश निष्क्रिय कर रहे हैं, NIO बचा सकता है धागे इसलिए स्मृति बचाने के लिए, और इस प्रणाली धागा प्रति कनेक्शन मॉडल की तुलना में एक बहुत अधिक उपयोगकर्ताओं संभाल कर सकते हैं।

सीपीयू यहां प्रत्यक्ष कारक नहीं है। एनआईओ के साथ, आपको प्रभावी ढंग से एक थ्रेडिंग मॉडल को लागू करने की आवश्यकता है, जो कि जेवीएम के धागे से तेज होने की संभावना नहीं है।

या तो चुनाव में, स्मृति परम टोंटी है। जब भार बढ़ता है और स्मृति का उपयोग अधिकतम होता है, तो जीसी बहुत व्यस्त हो जाएगा, और सिस्टम अक्सर 100% सीपीयू का लक्षण प्रदर्शित करता है।

Answer 3

कुछ समय पहले मुझे rather interesting presentation "पुराना थ्रेड-प्रति-क्लाइंट मॉडल बेहतर क्यों है" पर कुछ अंतर्दृष्टि प्रदान करता है। माप भी हैं। हालांकि मैं अभी भी इसके माध्यम से सोच रहा हूँ। मेरी राय में इस सवाल का सबसे अच्छा जवाब "यह निर्भर करता है" क्योंकि अधिकांश (यदि नहीं सभी) इंजीनियरिंग निर्णय व्यापार बंद हैं।

Answer 4

उस प्रस्तुति की तरह कहा - गति है और स्केलेबिलिटी है।

एक परिदृश्य जहां थ्रेड-प्रति-अनुरोध लगभग निश्चित रूप से किसी भी एसिंक समाधान से तेज़ होगा, जब आपके पास अपेक्षाकृत कम संख्या में ग्राहक हों (उदा। < 100), लेकिन प्रत्येक ग्राहक बहुत अधिक मात्रा में है। जैसे एक रीयलटाइम ऐप जहां 100 से अधिक ग्राहक 500 संदेशों को एक दूसरे को भेज रहे/उत्पन्न नहीं कर रहे हैं। थ्रेड-प्रति-अनुरोध मॉडल निश्चित रूप से किसी भी async ईवेंट लूप समाधान से अधिक कुशल होगा। कई अनुरोध/क्लाइंट होने पर असिंक स्केल बेहतर होता है क्योंकि यह कई क्लाइंट कनेक्शन पर इंतजार कर रहे चक्रों को बर्बाद नहीं करता है, लेकिन जब आपके पास कम प्रतीक्षा वाले कुछ उच्च मात्रा वाले क्लाइंट होते हैं, तो यह कम कुशल होता है।

जो मैंने देखा, उससे नोड और नेटटी के लेखक दोनों यह मानते हैं कि इन ढांचे का मुख्य रूप से उच्च मात्रा वाले ग्राहकों की एक छोटी संख्या के लिए तेजी से होने के बजाय उच्च मात्रा/कई कनेक्शन स्केलेबिलिटी स्थितियों को संबोधित करना है।