RabbitMQ स्थानांतरण दर तेज है?

Question

मैं विचारों को देखता हूं कि कैसे RabbitMQ के माध्यम से संदेश स्थानान्तरण को गति देना है।

मैंने विंडोज 64 बिट पर नवीनतम संस्करण स्थापित किया है, जो मेरी स्थानीय मशीन पर एक सर्वर चला रहा है जिस पर मैं सी # कार्यान्वयन के माध्यम से/से भी प्रकाशित/उपभोग करता हूं। मैंने शुरुआत में प्रति सेकंड 40,000 संदेशों को अधिकतम किया जो प्रभावशाली है लेकिन मेरी ज़रूरतों के अनुरूप नहीं है (मैं एक कस्टम बाइनरी रीडर के साथ प्रतिस्पर्धा करता हूं जो प्रति सेकंड 24 मिलियन अनपेक्षित 16 बाइट बड़े बाइट एरे को संभाल सकता है; जाहिर है कि मैं इसके करीब आने की अपेक्षा नहीं करता लेकिन मैं कम से कम सुधार करने का प्रयास करता हूं)। मुझे जितनी जल्दी हो सके 115,000,000 संदेश भेजने की जरूरत है। मैं डेटा को जारी रखना नहीं चाहता हूं और कनेक्शन एक ही उपभोक्ता के लिए सीधे होगा। मैंने फिर अपने 16 बी बाइट एरे के टुकड़े बनाए और बिना किसी सुधार के बस पर प्रकाशित किया। स्थानांतरण दर 45 एमबी/सेकेंड पर अधिकतम हो गई। मुझे यह तथ्य बहुत धीमा लगता है कि अंत में इसे केवल कच्ची संचरण की गति में उबालना चाहिए क्योंकि मैं बाइट एरे कई मेगाबाइट्स के आकार को बना सकता हूं, जहां एक्सचेंज द्वारा रूटिंग की दक्षता दर नगण्य बनाम कच्ची संचरण गति बन जाती है। मेरी संदेश बस 45 एमबी/दूसरी स्थानांतरण गति पर अधिकतम क्यों है?

Answer 1

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

एक श्वेत पत्र था जिसमें यह वर्णन किया गया था कि उन्होंने कम विलंबता, उच्च थ्रुपुट विकल्प वित्तीय डेटा धाराओं के प्रबंधन के लिए समाधान कैसे प्रदान किया था, लेकिन यह मुझे लगता है कि वे कम लेटेंसी को लक्षित करने वाले समाधान प्रदान करने के बजाय हार्डवेयर पर फेंक रहे थे, उच्च थ्रूपुट आवश्यकताओं।

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