RabbitMQ संदेश प्रसंस्करण का अनुकूलन

काम के कार्यों के हिस्से के रूप में, मैंने हाल ही में RabbitMQ संदेश ब्रोकर के साथ काम करते समय प्रीफैकटकाउंट विकल्प का उपयोग करने की सलाह पर एक छोटा अध्ययन किया।
मैं इस सामग्री को उन पर स्लाइड और टिप्पणियों के रूप में साझा करना चाहता हूं।

टेस्ट एक विशिष्ट परियोजना पर किए गए थे, लेकिन सामान्य तौर पर वे ज्यादातर मामलों के लिए मान्य होते हैं जहां संदेश संसाधित करना (कार्य पूरा करना) कम से कम कुछ महत्वपूर्ण समय (जब 1000 संदेश प्रति सेकंड से कम प्रसंस्करण होता है) होता है।

* स्लाइड पर, "उपभोक्ता" शब्द के बजाय, "उपभोक्ता" का उपयोग किया जाता है, एकरूपता के लिए टिप्पणियों में भी
* पांच उपभोक्ताओं के साथ एक एकल कतार मानी जाती है (C1..C5)

आदर्श स्थिति

इस तरह की तस्वीर देखी जा सकती है अगर सभी संदेशों के प्रसंस्करण में बिल्कुल समान समय लगता है। PrefetchCount = 0 के साथ, उपभोक्ताओं को बदले में संदेश वितरित किए जाते हैं, भले ही कितने संदेशों की पुष्टि न की गई हो।

समान कार्य

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

असमान कार्य

यदि कार्य जटिलता में महत्वपूर्ण रूप से भिन्न हो सकते हैं [उदाहरण के लिए, प्रसार हमारी परियोजना पर आदेशों की एक जोड़ी है] , तो जब आपको एक संदेश प्राप्त होता है जिसे संसाधित होने में लंबा समय लगता है, तो अनजाने संदेशों की संख्या जमा हो जाएगी। नेत्रहीन (कतार की निगरानी), ऐसा लगता है कि संदेश लटक रहे हैं, क्योंकि मुफ्त उपभोक्ता तुरंत नए संदेशों को संसाधित करेंगे, और संदेश एक व्यस्त संदेश में जमा हो जाएंगे। इन संदेशों को अन्य उपभोक्ताओं को प्रसंस्करण के लिए नहीं भेजा जाएगा, जब तक कि प्रसंस्करण का कनेक्शन आरेख में नहीं गिरता - C4] । इस मामले में भी, मुफ्त उपभोक्ताओं के लिए महत्वपूर्ण डाउनटाइम हैं।

महाकाव्य असफल

पुनः आरंभ

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

ऐसी स्थिति में जब कोई संदेश कतार में होता है, उपभोक्ताओं की शुरुआत में, उनमें से एक इसे प्राप्त करता है। जब इसके बाद कोई अन्य संदेश आता है, तो उसे उसी उपभोक्ता को भेज दिया जाता है । इसका कारण पॉइंटर का रीसेट हो सकता है, जैसा कि प्रसंस्करण के लिए पहला संदेश भेजे जाने के बाद से उपभोक्ताओं की संख्या में बदलाव आया है।

उचित प्रेषण

PrefetchCount = n विकल्प का उपयोग करते समय [उदाहरण n = 1 में, लेकिन शायद 2, 5, 10 ...], उपभोक्ता को अगले n संदेश तब तक प्राप्त नहीं होंगे जब तक वह पिछले वाले की पुष्टि नहीं करता है। इस प्रकार, आप कार्यों की जटिलता की एकरूपता की परवाह किए बिना, एक समान कार्यभार प्राप्त कर सकते हैं। जब कतार में संदेश होते हैं, तो कोई स्थिति नहीं होगी, और कुछ उपभोक्ता निष्क्रिय होते हैं (यदि निष्क्रिय है, तो कतार में प्रति उपभोक्ता n संदेशों से अधिक नहीं होगा)।

प्रदर्शन RabbitMQ

लेकिन इतना सरल नहीं है। कम प्रीफ़ैकटकाउंट मान, RabbitMQ का कम प्रदर्शन (0 का मान अनंत से मेल खाता है और चार्ट पर 10000 के मान के करीब है)। यह चार्ट आधिकारिक साइट से लिया गया है।



एक ही ग्राफ, केवल प्रीफैकटाउंट के मूल्य पर निर्भर करता है, और उपभोक्ताओं की संख्या पर नहीं।
यह दर्शाता है कि प्रीफ़ैकटाउंट = 1 के लिए 5 उपभोक्ताओं के साथ , रैबिटएमक्यू प्रति सेकंड 10k संदेश भेजने में सक्षम होगा, और प्रीफ़ैचटाउन = 0 के लिए - 36k संदेश प्रति सेकंड, जो कि 3.6 गुना अधिक है।

उपभोक्ता का प्रदर्शन

लेकिन ज्यादातर मामलों में अड़चनें रैबिटक्यू का प्रदर्शन नहीं होगा, बल्कि उपभोक्ताओं का प्रदर्शन (परिमाण कम होने के कई आदेश) होगा। परीक्षण परियोजना पर, प्रीफ़ैचेकाउंट के मूल्य पर इस तरह की निर्भरता (या बल्कि, इसकी अनुपस्थिति) थी [यह उचित होगा, जैसा कि मैंने पहले ही उल्लेख किया है, उन उपभोक्ताओं के लिए जो प्रति सेकंड 1000 से कम संदेशों को संसाधित करते हैं] ।



उसी समय, उपभोक्ताओं की संख्या पर उत्पादकता की निर्भरता [हमारी परियोजना पर] समान हो गई, लेकिन यह वास्तव में उपभोक्ताओं के स्वयं के संसाधन उपभोग, सर्वर प्रदर्शन, चाहे उपभोक्ता विभिन्न सर्वरों पर स्थित हो, आदि पर निर्भर करता है।

निष्कर्ष

PrefetchCount = 1 (पहली स्लाइड से आदर्श स्थितियों की तुलना में) के उपयोग के कारण अधिकतम नुकसान 0.03% हैं। इसी समय, समान वितरण और कम डाउनटाइम के कारण अपेक्षित समय लाभ लगभग 50..100% (1.5..2.2%) होगा, क्योंकि वास्तविक कतार में, prefetchCount = 0 के साथ , संदेश प्रसंस्करण समय अक्सर डाउनटाइम के बाकी हिस्सों (तीसरी स्लाइड पर) के कारण काम करने वाले एक उपभोक्ता के समय के लिए नीचे आता है। इसके अलावा, कतार अधिक अनुमानित रूप से चलती है, और "फ्रीज" का कोई प्रभाव नहीं है।

[बेशक, अन्य परियोजनाओं के लिए, संख्या अलग होगी]

मैं आपके परीक्षणों और टिप्पणियों के परिणामों को टिप्पणियों में प्रीफैचाउंट से संबंधित साझा करने का सुझाव देता हूं।