2008-09-19 19 views
15

ज़ीरोक का आईसीई (www.zeroc.com) दिलचस्प लग रहा है और मुझे इसे देखने और डब्ल्यूसीएफ का उपयोग करने वाले हमारे मौजूदा सॉफ़्टवेयर की तुलना करने में दिलचस्पी है। विशेष रूप से, हमारे डब्ल्यूसीएफ ऐप सर्वर कॉलबैक (HTTP के माध्यम से) का उपयोग करता है।क्या किसी ने डब्ल्यूसीएफ और ज़ीरोसी आईसीई की तुलना की है?

कोई भी जिसकी तुलना उनकी तुलना की जाती है? यह कैसे हुआ? मैं विशेष रूप से प्रदर्शन पहलू में रूचि रखता हूं, क्योंकि इंटरऑपरेबिलिटी अभी हमारे लिए चिंता का विषय नहीं है। धन्यवाद!

+1

यदि आप तुलना स्वयं करते हैं। कृपया यहां अपने विचार पोस्ट करें। –

उत्तर

13

मैंने कुछ साल पहले आईसीई की बहुत कम समीक्षा की थी, और हालांकि मैंने उन्हें पहले तुलना नहीं की है, डब्ल्यूसीएफ के उचित ज्ञान के साथ मेरे विचारों में कुछ प्रासंगिकता हो सकती है।

सबसे पहले, डब्ल्यूसीएफ की तुलना में डब्ल्यूसीएफ की तुलना में डब्ल्यूसीएफ के रूप में तुलना करने के लिए यह उचित नहीं है क्योंकि आईसीई एक विशिष्ट रिमोट संचार तंत्र है और डब्ल्यूसीएफ एक उच्च स्तरीय रिमोट संचार ढांचा है।

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

तुलना में, आईसीई एक क्रॉस-प्लेटफार्म रिमोट कम्युनिकेशन तंत्र है जो अनुप्रयोगों के बीच प्रदर्शन संचार के लिए बाइनरी एन्कोडिंग का उपयोग करता है। यह कॉर्बा के सरलीकृत विकास का कुछ है और यह सीधे कोर्बा, डीसीओएम, .NET Remoting, और जेएनआई से तुलनात्मक है।

हालांकि, आईसीई और डब्ल्यूसीएफ के बीच कोई प्रत्यक्ष पत्राचार नहीं है, भले ही आपको अपने .NET ऐप को दूरस्थ रूप से संवाद करने की आवश्यकता हो, तो वे दोनों दावेदार हैं। कुछ निर्णय बिंदु जिन्हें आप विचार करना चाहते हैं उनमें शामिल हैं:

  • संसाधन। आईसीई अनुभव की तुलना में डब्ल्यूसीएफ अनुभव के साथ डेवलपर्स को ढूंढना आसान होगा।

  • प्रदर्शन। यदि आप प्रदर्शन चाहते हैं तो आईसीई तेजी से प्रदर्शन करता है, लेकिन डब्ल्यूसीएफ का उपयोग एक प्रदर्शन कॉन्फ़िगरेशन में भी किया जा सकता है। वैकल्पिक रूप से, .NET Remoting बहुत अच्छा प्रदर्शन प्रदान कर सकता है, और एमएस प्रायोजित बेंचमार्क जो कुछ भी कहता है मैंने इसे डब्ल्यूसीएफ को 10% से बेहतर प्रदर्शन किया है।

  • क्रॉस-प्लेटफ़ॉर्म। यदि आपको गैर-विंडोज अनुप्रयोगों के साथ संवाद करने की आवश्यकता है तो आप डब्लूसीएफ विकल्पों के साथ सीमित हैं जिनका आप उपयोग कर सकते हैं। इसके अलावा, के बाद से हर SOAP स्टैक मानकों को अलग ढंग से लागू करने के लिए लगता है कि यह एक दर्द वास्तव में सामान्य वेब सेवा बनाने जा सकता है (हालांकि WS-मैं मदद करता है)

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

+0

धन्यवाद। असल में हमारी वर्तमान प्रणाली पहले से ही डब्ल्यूसीएफ (wsDualHttp बाइंडिंग) का उपयोग कर रही है, इसलिए मैं आईसीई पर भी विचार कर रहा हूं, अगर यह बेहतर प्रदर्शन या स्केलेबिलिटी प्रदान कर सकता है। – cruizer

+1

सर्वोत्तम मामले के लिए मेरे स्वयं के परीक्षण .NET Remoting स्थिति (इन-प्रोसेस क्रॉस-ऐपडोमेन विधि कॉल) दिखाते हैं कि डब्ल्यूसीएफ उस विशेष स्थिति में वास्तव में तेज़ है। YMMV। – Mark

+1

हमने लोड संतुलन मोड में आईसीई का उपयोग किया है, जिसके लिए सर्वर कोड में कोई बदलाव की आवश्यकता नहीं है। जब हमने अपडेट किया तो यह स्वचालित रूप से सभी नोड्स के अपडेट को धक्का देता है। डब्ल्यूसीएफ इनमें से किसी का समर्थन नहीं करता है। – Contango

11

Michi ज़ीरो से हेनिंग हाल ही में इस विषय पर publisheda white paper है - "मिडलवेयर चुनना: प्रदर्शन और स्केलेबिलिटी क्यों करें (और नहीं) मैटर"। यह बर्फ, डब्ल्यूसीएफ (बाइनरी & एसओएपी) की तुलना करता है, और विभिन्न प्रदर्शन मीट्रिक, प्लेटफार्मों, भाषाओं आदि के साथ आरएमआई। Michi's blog पर अधिक जानकारी है, लेकिन श्वेत पत्र भी किसी भी बेंचमार्क की सभी मानक चेतावनी के साथ काफी पठनीय है।

अस्वीकरण: मैंने बर्फ और आरएमआई का व्यापक रूप से उपयोग किया है, लेकिन कभी भी डब्ल्यूसीएफ नहीं।

+1

व्हाइटपेपर हाल ही में अपडेट किया गया था (16 फरवरी, 2011) http://www.zeroc.com/forums/announcements/5250-performance-white-paper-updated-ice-3-4-1-a.html – MKroehnert

0

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

मैंने डब्ल्यूसीएफ और आईसीई दोनों का उपयोग किया है, और मैं कहूंगा कि आईसीई कार्यान्वयन पक्ष पर क्लीनर है। आईसीई में भी बहुत विस्तृत और पठनीय दस्तावेज है।

बर्फ लोड संतुलन, स्वचालित दूरस्थ क्लाइंट अद्यतन, आदि

2

Apache Thrift बर्फ और WCF के लिए एक और दावेदार है सहित, कुछ चीजें हैं जो WCF ऐसा नहीं कर सकते का समर्थन करता है। यह फेसबुक द्वारा विकसित और खुलासा किया गया था। Apache Thrift कुछ तरीकों से अच्छा है क्योंकि यह न केवल एन्कोडिंग पक्ष पर बेहद कुशल है, यह सभी ग्राहकों को तोड़ने के बिना संरचनाओं में फ़ील्ड जोड़ने का भी समर्थन करता है (कुछ जो हमें हमारी परियोजनाओं के लिए बेहद उपयोगी पाया जाता है)।

Google Protocol Buffers वास्तव में एक प्रतियोगी प्रतीत नहीं होता क्योंकि यह होम पेज पर .NET समर्थन का उल्लेख नहीं करता है। हालांकि, कुछ समुदाय एडॉन्स सी # का समर्थन करते हैं। इसके अतिरिक्त, ICE यदि आप मौजूदा सेवाओं के साथ काम कर रहे हैं तो Google प्रोटोकॉल बफर के लिए अनुकरण प्रदान करता है।

+2

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

1

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

मैंने अभी बेंचमार्किंग समाप्त कर दी है, और हमारे आवेदन में जो कुछ भी बड़ी मात्रा में डेटा को धक्का देता है वह बर्फ से बराबर या उसके बराबर है। अधिक ओवर-हेड के साथ छोटे संदेश (यानी, एक "दिल की धड़कन" जो प्रोटोकॉल पर स्थिति अपडेट करता है) थोड़ा धीमा है।

सबसे महत्वपूर्ण बात यह थी कि कॉलबैक सेवा को सही ढंग से कार्यान्वित करने के लिए हमें थ्रिफ्ट इंटरफेस का विस्तार करना था और एक थ्रिफ्ट "प्रोसेसर" और कॉलबैक क्लाइंट-सर्वर के साथ अपने स्वयं के प्रोटोकॉल को परिभाषित करना था। लेकिन मैं स्वतंत्र रूप से स्वीकार करता हूं कि हमारा आवेदन/बहुत/विशेष है। मौजूदा प्रोटोकॉल और सर्वर पर्याप्त होना चाहिए। लेकिन उन्हें विस्तारित करना, नेट से मल्टीप्लेक्स सॉकेट का उपयोग करने के लिए भी, बहुत मुश्किल नहीं था।