नेट्टी बनाम अपाचे MINA

Question

वे दोनों मोटे तौर पर एक ही कार्यक्षमता प्रदान करते हैं। मुझे अपने उच्च प्रदर्शन वाले टीसीपी सर्वर को विकसित करने के लिए कौन सा चुनना चाहिए? पेशेवरों और विपक्ष क्या हैं?

संदर्भ लिंक:

Apache MINA ( स्रोत )

नेट्टी ( स्रोत )

Comments

तुलना करने के लिए ग्रिज़ली को जोड़ना भी दिलचस्प होगा।

— मार्क

ग्रिजली पूरी तरह से अलग जानवर है। यहां तक ​​कि MINA के लिए ग्रिज़ली समर्थन का विचार भी था, जब दोनों समूहों ने बात की थी।

— हार्डकॉस्ट 13

@ हर्डकोड आप कहते हैं कि ग्रिजली पूरी तरह से एक अलग जानवर है, मैं इस पर एक नया काम कर रहा हूं, क्या आप मतभेदों को इंगित कर सकते हैं या मुझे उस पर पढ़ने के लिए एक लेख दे सकते हैं? मैं वास्तव में इसकी सराहना करूंगा।

— arg20

ग्रिज़ली की एक अलग पृष्ठभूमि है और पिछली बार जब मैं इसे देखता हूं, तो यह ज्यादातर HTTP- आधारित अनुप्रयोगों के अनुकूल था। मैंने सिर्फ उदाहरणों को देखा और यह देखकर आश्चर्यचकित रह गया कि वे बहुत समान संरचना का उपयोग कर रहे हैं जैसे कि MINA या Netty। इसलिए जानवर अब अलग नहीं है

— हार्डकूटेड

Answer 1

जबकि MINA और Netty की समान महत्वाकांक्षाएं हैं, वे व्यवहार में काफी भिन्न हैं और आपको अपनी पसंद पर ध्यान से विचार करना चाहिए। हम भाग्यशाली थे कि हमारे पास MINA के साथ बहुत अनुभव था और नेट्टी के साथ खेलने का समय था। हमें विशेष रूप से क्लीनर एपीआई और बहुत बेहतर प्रलेखन पसंद आया। पेपर पर भी प्रदर्शन बेहतर रहा। इससे भी महत्वपूर्ण बात यह है कि हम जानते हैं कि ट्रस्टिन ली हमारे पास मौजूद किसी भी प्रश्न का उत्तर देने के लिए हैं, और उन्होंने निश्चित रूप से ऐसा किया।

हमने नेटी में सब कुछ आसान पाया। अवधि। जब हम उसी कार्यक्षमता को फिर से लागू करने की कोशिश कर रहे थे जो हमारे पास पहले से ही MINA पर थी, तो हमने खरोंच से ऐसा किया। उत्कृष्ट प्रलेखन और उदाहरणों का पालन करके हमने बहुत अधिक, बहुत कम कोड में अधिक कार्यक्षमता के साथ समाप्त किया।

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

लेकिन नेटी, इहो के स्टार आकर्षण, "एक के कवरेज" के साथ पाइपलाइन हैंडलर बनाने की क्षमता है। आपने शायद इस कवरेज एनोटेशन के बारे में पहले से ही प्रलेखन में पढ़ा है, लेकिन अनिवार्य रूप से यह आपको कोड की एक पंक्ति में राज्य देता है। कोई गड़बड़ नहीं होने के साथ, कोई सत्र मानचित्र, तुल्यकालन और उस तरह का सामान नहीं है, हम बस नियमित चर घोषित करने में सक्षम थे (जैसे, "उपयोगकर्ता नाम") और उनका उपयोग करें।

लेकिन फिर हमने एक सड़क को मारा। हमारे पास पहले से ही MINA के तहत एक बहु-प्रोटोकॉल सर्वर था, जिसमें हमारे एप्लिकेशन प्रोटोकॉल TCP / IP, HTTP और UDP पर चलते थे। जब हमने नेटी पर स्विच किया तो हमने एसएसटी और एचटीटीपीएस को कुछ ही मिनटों में सूची में जोड़ दिया! अब तक तो अच्छा है, लेकिन जब यूडीपी की बात आई तो हमने महसूस किया कि हम फिसल गए थे। MINA हमें बहुत अच्छा लगा कि हम UDP को एक "कनेक्टेड" प्रोटोकॉल के रूप में मान सकते हैं। नेट्टी के तहत ऐसा कोई अमूर्तन नहीं है। UDP कनेक्शन रहित है और Netty इसे इस तरह मानता है। MINA की तुलना में नेट्टी UDP के कम स्तर पर अधिक कनेक्शन रहित प्रकृति को उजागर करता है। ऐसी कई चीजें हैं जो आप यूडीपी के साथ नेट्टी के तहत कर सकते हैं, जितना कि आप उच्च-स्तरीय अमूर्तता के तहत नहीं कर सकते हैं जो कि मिनिया प्रदान करती है, लेकिन जिस पर हम निर्भर थे।

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

इसलिए, उन दोनों के बीच के अंतरों को देखें और जल्दी से एक ऐसे मंच पर पहुँच जाएँ जहाँ आप परीक्षण कर सकें कि कोई ट्रिकी कार्यक्षमता अपेक्षित है। यदि आप इस बात से संतुष्ट हैं कि नेटी काम करेगा, तो मैं इसके साथ MINA पर जाने में संकोच नहीं करूंगा। अगर आप MINA से Netty की ओर बढ़ रहे हैं, तो वही लागू होता है, लेकिन यह ध्यान देने योग्य है कि दो API वास्तव में काफी भिन्न हैं और आपको Netty के लिए एक वर्चुअल फिर से लिखना चाहिए - आपको इसका अफसोस नहीं होगा!

Comments

पुन: पहले जोश द्वारा नेट्टी में यूडीपी के लिए समर्थन की कमी पर टिप्पणी: मुझे समझ में नहीं आता कि आप नेटी को छोड़ने के बजाय हाथ से तैयार किए गए कोड के कुछ पन्नों का उपयोग क्यों नहीं कर सकते हैं। यूडीपी वैसे भी एक अलग बंदरगाह पर सुन रहा है। मैं नेट्टी बनाम नग्नेक्स का परीक्षण कर रहा हूं और काफी प्रभावित हूं (नेटी उसी के बारे में स्कोरिंग कर रहा है, या लोड के तहत बेहतर है)।

Answer 2

जटिलता और अपेक्षाकृत खराब प्रदर्शन की कीमत पर MINA की आउट-ऑफ-द-बॉक्स सुविधाएँ हैं। उन विशेषताओं में से कुछ को कोर में एकीकृत किया गया था, भले ही उन्हें किसी उपयोगकर्ता की आवश्यकता न हो। नेटी में, मैंने MINA की ज्ञात शक्तियों को बनाए रखते हुए इस तरह के डिजाइन मुद्दों को संबोधित करने की कोशिश की।

वर्तमान में, MINA में उपलब्ध अधिकांश सुविधाएँ Netty में भी उपलब्ध हैं। मेरी राय में, Netty में क्लीनर और अधिक प्रलेखित एपीआई है क्योंकि Netty खरोंच से MINA के पुनर्निर्माण और ज्ञात मुद्दों को संबोधित करने की कोशिश का परिणाम है। यदि आप पाते हैं कि एक आवश्यक सुविधा गायब है, तो कृपया अपने सुझाव को मंच पर पोस्ट करने के लिए स्वतंत्र महसूस करें। मुझे आपकी चिंता का समाधान करने में खुशी होगी।

यह भी ध्यान रखना महत्वपूर्ण है कि नेट्टी में तेजी से विकास चक्र है। बस, हालिया रिलीज की रिलीज़ डेट देखें। इसके अलावा, आपको यह विचार करना चाहिए कि MINA टीम एक प्रमुख पुनर्लेखन, MINA 3 के लिए आगे बढ़ेगी, जिसका अर्थ है कि वे एपीआई संगतता को पूरी तरह से तोड़ देंगे।

Comments

ओह, @ क्रस्टिन MINA और Netty दोनों के लेखक हैं।

— जेसन हीओ

@trustin, मैंने पाया कि Netty 5.0 बहुत उन्नत दस्तावेज़ प्रदान नहीं करता है, और अन्य संस्करण के साथ वर्तमान वेब सामग्री काम नहीं करेगी। क्या आपके पास मध्यवर्ती और उन्नत मीना ट्यूटोरियल के लिए कोई अनुशंसा लिंक है? धन्यवाद

— कोरबेन

Answer 3

मैंने प्रदर्शन 2 "Google Protobuffer RPC" कार्यान्वयन का परीक्षण किया जहां एक नेट्टी (netty-protobuf-rpc) पर आधारित था और दूसरा मीना (protobuf-mina-rpc) पर आधारित था। नेट्टी सभी संदेश आकारों के लिए लगातार तेज (+ - 10%) समाप्त हुई - जो कि नेट्टी वेब साइट पर समग्र प्रदर्शन के दावे का समर्थन करती है। चूँकि जब आप ऐसी RPC लाइब्रेरी का उपयोग करते हैं, तो आप अपने कोड से हर तरह की दक्षता को निचोड़ सकते हैं, मैंने Netty पर आधारित protobuf-rpc-pro लिखना समाप्त कर दिया है । मैंने अतीत में MINA का उपयोग किया है, लेकिन पाते हैं कि 2.0 सामान के उनके प्रलेखन में बड़े छेद हैं, और एपीआई पिछड़े संगतता को एक बड़े ऋण के रूप में तोड़ते हैं।

Answer 4

MINA और Netty शुरू में एक ही लेखक द्वारा डिजाइन और निर्मित किए गए थे। यही कारण है कि वे एक-दूसरे के प्रति इतने सहज हैं। MINA को थोड़ा और अधिक सुविधाओं के साथ उच्च स्तर पर डिज़ाइन किया गया है, जबकि Netty थोड़ी तेज़ है। मुझे लगता है कि बहुत अंतर नहीं है, मूल अवधारणाएं समान हैं।

Answer 5

नेट्टी साइट में आप कुछ प्रदर्शन रिपोर्ट पा सकते हैं । जैसा कि उम्मीद थी :-) वे सबसे अच्छा प्रदर्शन के साथ रूपरेखा के रूप में नेति बताते हैं।

मैंने कभी भी Netty का उपयोग नहीं किया, लेकिन मैंने TCP प्रोटोकॉल को लागू करने के लिए पहले ही MINA का उपयोग कर लिया था। एन्कोडिंग और डिकोडिंग का कार्यान्वयन आसान था, लेकिन राज्य मशीन का कार्यान्वयन इतना आसान नहीं था। राज्य मशीन को लागू करते समय MINA आपकी सहायता करने के लिए कुछ कक्षाएं प्रदान करता है, लेकिन मैंने उन्हें उपयोग करने में कठिन पाया। अंत में हमने MINA को खोदने और प्रोटोकॉल को खरोंच से लागू करने का फैसला किया, और आश्चर्यजनक रूप से हम एक तेज सर्वर के साथ समाप्त हो गए।

Answer 6

मुझे नेट्टी पसंद है।

ट्विटर ने अपना नया सर्च सिस्टम बनाने के लिए नेट्टी को भी चुना और इसे तेजी से 3x तक बढ़ाया।

Ref: Twitter खोज अब 3x तेज़ है

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

Answer 7

मैंने सर्वर की तरह एक छोटा http बनाने के लिए केवल MINA का उपयोग किया है। सबसे बड़ी समस्याएँ जो मैंने अब तक इसके साथ निभाई हैं:

1. यह आपके "अनुरोध" और "प्रतिक्रिया" को स्मृति में रखेगा। यह केवल एक समस्या है क्योंकि मैं जिस प्रोटोकॉल का उपयोग करना चाहता हूं वह है http। आप अपने स्वयं के प्रोटोकॉल का उपयोग कर सकते हैं, लेकिन इसके चारों ओर पाने के लिए।
2. यदि आप बड़ी फ़ाइलों की सेवा करना चाहते हैं, तो डिस्क से एक स्ट्रीम प्रदान करने का कोई विकल्प नहीं है। फिर से अपने प्रोटोकॉल को लागू करके चारों ओर काम किया जा सकता है

इसके बारे में अच्छी बातें:

1. बहुत सारे कनेक्शन संभाल सकते हैं
2. यदि आप किसी प्रकार की वितरित कार्य प्रणाली को लागू करना चुनते हैं, तो यह जानना कि कब आपका एक नोड नीचे चला जाता है और किसी अन्य नोड पर काम को फिर से शुरू करने के लिए कनेक्शन खो देता है।

Comments

जब आप कहते हैं "बड़ी फ़ाइलों के लिए डिस्क को स्ट्रीम करें", तो क्या लोग आमतौर पर इसके लिए यूडीपी का उपयोग नहीं करते हैं?

— djangofan

नहीं, वे टीसीपी के ऊपर कर्नेल सेंडफाइल (जावा में फाइलचैनलाइन ट्रान्सफेरटो के रूप में उजागर) का उपयोग करते हैं।

— जलेबिस