बढ़ावा देने पर IMAP :: asio

प्रारंभ में, हमारे IMAP सर्वर ने एक मालिकाना एपोल रिएक्टर का उपयोग किया था। हमेशा की तरह, लोड के संचालन और विकास के दौरान, टिप्पणी धीरे-धीरे आती है, जिसके परिणामस्वरूप तकनीकी ऋण समय के साथ जमा होने लगता है और विकास धीमा हो जाता है।

हमारे मामले में, शुरुआती स्थापत्य नोट भी थे।

• रिएक्टर की सेवा करने वाले प्रवाह को किसी भी तरह से नियंत्रित नहीं किया गया था और नियंत्रण संकेतों के आने पर दौड़-हालत हो सकती है। दूसरी ओर, इस प्रवाह को रोका या धीमा नहीं किया जा सकता है, इसलिए संभव बाईपास मार्ग अस्वीकार्य लग रहे थे।
• रिएक्टर को पता नहीं था कि फुल-डुप्लेक्स मोड में कैसे काम किया जाए। इसने इसके उपयोग को केवल इंटरएक्टिव प्रोटोकॉल तक सीमित कर दिया, जैसे कि IMAP। हालांकि, सर्वरों के बीच हम अक्सर IProto प्रोटोकॉल का उपयोग करते हैं, जिसका अर्थ है पूर्ण-द्वैध संचार।

IProto के बारे में गीतात्मक विषयांतर: प्रोटोकॉल बहुत सरल है: uint32_t प्रकार के तीन क्षेत्रों का एक हेडर: कमांड, पैकेट संख्या, डेटा लंबाई। "पैकेट नंबर" फ़ील्ड के कारण, सर्वर किसी भी क्रम में अनुरोधों का जवाब दे सकता है, और ग्राहक एक अतुल्यकालिक शैली में प्रतिक्रिया की प्रतीक्षा कर सकता है और अगला अनुरोध भेज सकता है। Mail.Ru Group में इसका उपयोग हर जगह किया जाता है - हमारे Tarantool के साथ शुरू होता है, और एंटी-ब्रूट बल सेवा के साथ समाप्त होता है।

इसलिए, यह बढ़ावा देने के लिए एक परीक्षण संस्करण बनाने का फैसला किया गया था :: asio। इस पोस्ट में, मैं बढ़ावा देने के बारे में बात करूँगा :: asio रिएक्टर, इसके फायदे और हमारे द्वारा सामना किए गए नुकसान।

आपने बढ़ावा क्यों चुना :: asio? आमतौर पर, एक अतुल्यकालिक अनुप्रयोग में एपोल का उपयोग करके मतदान सॉकेट से अधिक शामिल होता है। एक वास्तविक एप्लिकेशन में, आपको अभी भी टाइमर, थ्रेड्स, RC रोकथाम रणनीतियों, SSL के साथ सही संचालन, IPv6 के लिए मूल समर्थन की आवश्यकता है। बढ़ावा :: asio आपको यह सब C ++ शैली में एक प्राकृतिक तरीके से करने की अनुमति देता है।

पुनर्वास की प्रक्रिया

रिएक्टर को बदलना काफी सरल था। यह कई कारकों द्वारा मदद की गई थी।

• पुराने रिएक्टर में, पढ़ने / लिखने के बिंदुओं को कड़ाई से मानकीकृत किया गया था, जैसा कि रिएक्टर से ही बुलाए गए थे, इसलिए कॉलबैक पढ़ना / लिखना स्थापित करना आसान था। बेशक, अपवाद हैं, विशेष रूप से, शाब्दिक रूप से प्रसंस्करण और FETCH कमांड, जिसके लिए आपको लिखने वाले बफर के आकार को सीमित करने की आवश्यकता है।
• टाइमर ने रिएक्टर से ही अलग से काम किया, इसलिए इसे पूरी तरह से देशी द्वारा asio deadline_timer के लिए बदल दिया गया।
• Asio :: स्ट्रैंड का उपयोग RC रोकथाम रणनीति के रूप में किया जाता है।
• बढ़ावा :: asio ओपनएसएसएल का उपयोग करता है, जिसे एक सामान्य मानक के रूप में जाना जाता है। इसके अलावा, ओपनएसएसएल में एक स्ट्रीम की एन्क्रिप्शन गति अन्य पुस्तकालयों ( प्रमाण ) की तुलना में काफी अधिक है।

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

सामान्य तौर पर, पहले रिलीज संस्करण में सर्वर की स्थिरता और जवाबदेही में वृद्धि पहले से ही स्पष्ट थी, जो निश्चित रूप से प्रसन्न है। बेशक, सब कुछ इतना रसीला नहीं था - कुछ समस्याएं थीं। उदाहरण के लिए, asio :: स्ट्रैंड के साथ, कनेक्शन ऑब्जेक्ट्स के उचित आत्म-विनाश की स्थापना के साथ, "भारी" APPEND, COPY, FETCH संचालन के साथ, बढ़ावा देने के साथ :: asio :: streambuf, जो मेमोरी देना पसंद नहीं करता है। लेकिन सबसे पहली बात।

सर्वर संरचना

संरचना को बढ़ावा देने से HTTP सर्वर 3 के समान है :: asio उदाहरण।
इवेंट थ्रेड पूल द्वारा परोसे जाते हैं, जो एक io_service :: रन का उदाहरण देता है। यह आपको उच्च सर्वर जवाबदेही प्राप्त करने की अनुमति देता है, जैसा कि कोई भी निशुल्क थ्रेड इवेंट हैंडलर को निष्पादित कर सकता है यदि वह निष्पादित होने के लिए तैयार है।

प्रत्येक क्लाइंट के साथ कनेक्शन की स्थिति को वर्ग के अपने उदाहरण द्वारा परोसा जाता है, जो टाइमआउट प्राप्त / प्रसारित / ट्रैक करने के बुनियादी कार्यों को लागू करता है। इसके अलावा, RFC के अनुसार राज्य की कक्षाएं इसे विरासत में मिली हैं: अनधिकृत, अधिकृत। बेस क्लास में कनेक्शन टाइमआउट की निगरानी के लिए डेडलाइन_टाइमर क्लास के उदाहरण हैं, एक सॉकेट डिस्क्रिप्टर (हमारे मामले में यह asio :: ssl :: स्ट्रीम है, क्योंकि एसएसएल एन्क्रिप्शन इसमें एनकैप्सुलेट किया गया है), एसियो - स्ट्रैंड को इवेंट हैंडलर के युगपत ट्रिगर्स को रोकने के लिए। (चूंकि वे एक ही वर्ग के तरीके हैं, दौड़ की स्थिति को रोका जाना चाहिए)।

एक अलग श्रोता वर्ग है जो बंदरगाहों पर सुनता है, उन पर कनेक्शन स्वीकार करता है, और SSL हैंडशेक सेट करता है। इसके हैंडलर एक ही थ्रेड पूल में काम करते हैं।

विभिन्न "भारी" ऑपरेशन एक विशेष तरीके से किए जाते हैं। लंबे समय तक स्ट्रैंड को ब्लॉक करना अवांछनीय है, और कमांड काफी लंबे हो सकते हैं (उदाहरण के लिए, COPY)। इसलिए, एक वर्कअराउंड का उपयोग किया जाता है जो आपको आरसी के संदर्भ में एक सुरक्षित मोड में यह काम शुरू करने की अनुमति देता है, लेकिन साथ ही स्ट्रैंड को ब्लॉक नहीं करता है। आदेश प्राप्त होने पर, सर्वर बस यह जांचता है कि सभी पैरामीटर सही हैं, उन्हें याद करता है, उन सभी घटनाओं को डिस्कनेक्ट करता है जो RC का कारण बन सकती हैं, और फिर io_service :: पोस्ट के माध्यम से एक विधि को कॉल करता है जो वास्तव में कार्रवाई करता है। यह पता चलता है कि कार्रवाई deattached मोड में होती है, अन्य अनुरोधों को करने के लिए अपने अवरोधन के साथ हस्तक्षेप किए बिना।

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



कैसे asio लोड के तहत व्यवहार करता है

संक्षेप में - ठीक है। आमतौर पर एक सामने के छोर पर लगभग 40 हजार ग्राहक कनेक्शन होते हैं। प्लस कुछ और - आंतरिक सेवाओं के लिए: डेटाबेस, स्टोरेज, आदि। इन सभी को आसियो रिएक्टर द्वारा नियंत्रित नहीं किया जाता है, लेकिन अभी तक यह पर्याप्त है। CPU शायद ही कभी 10-20% से आगे जाता है। मेमोरी के साथ सब कुछ इतना आसान नहीं है: कनेक्शन की इस संख्या के साथ, इसकी खपत 6-7 जीबी के स्तर पर है, मुख्य रूप से कुछ प्रोटोकॉल कमांड और एसएसएल मेमोरी खपत की गंभीरता के कारण।

शायद कई लोगों ने 10K मुद्दे के बारे में सुना है। तो, asio के लिए यह पूरी तरह से एक समस्या नहीं है, खासकर अगर आपके पुस्तकालयों और उप-प्रणालियों गैर-अवरुद्ध मोड में काम कर सकते हैं। शायद यह asio पर आवेदन का सबसे महत्वपूर्ण बिंदु और सामान्य रूप से अतुल्यकालिक अनुप्रयोग है। जब यह बिंदु हल हो जाता है, तो आप सैकड़ों हजारों कनेक्शनों की सेवा कर सकते हैं, यदि, निश्चित रूप से, आपके पास पर्याप्त मेमोरी और सीपीयू है। इसलिए मुझे लगता है कि आधुनिक दुनिया में C100K या C1M की समस्या के बारे में बात करना उचित है।

लेकिन वास्तव में ...

क्या हमने आसियो के कार्यान्वयन के साथ नुकसान का सामना किया है? बेशक हाँ। लेकिन, मेरी राय में, वे बहुत आसान हैं। चलिए शुरू करते हैं।

पहला आसियो :: स्ट्रैंड है। जो लोग जानते नहीं हैं, उनके लिए यह ऐसा सहायक है जो अपने तर्क से कॉलबैक को लपेटना जानता है; यह विभिन्न थ्रेड्स कॉलबैक में कॉलिंग की अनुमति नहीं देता है जो स्ट्रैंड के एक उदाहरण के साथ लिपटे थे। यह एक बहुस्तरीय वातावरण में घटना संचालकों की सुरक्षा सुनिश्चित करता है। लेकिन यह पनीर मुक्त नहीं निकला, लेकिन बात यह है: खुद के अंदर किस्में तथाकथित "स्ट्रैंड कार्यान्वयन" का उपयोग करती हैं , और संकलन संख्या पर उनकी संख्या को सीवन किया जाता है। बाद में, म्यूटेक्स-एस होते हैं। इससे क्या होता है? मान लीजिए कि हमारे पास ए, बी, सी, और स्ट्रैंड कार्यान्वयन की संख्या 2 है। यदि कनेक्शन में से एक में एक लंबा ऑपरेशन होता है, उदाहरण के लिए ए, तो तनाव आवंटन के क्षण में बी और सी कनेक्शन एक ही में गिर सकते हैं। कार्यान्वयन, जैसे ए। तब उनके सभी हैंडलर अवरुद्ध हो जाएंगे जब तक कि ए ऑपरेशन पूरा नहीं करता है। इस अर्थ में, कनेक्शन हैंडलर पर एक सरल म्यूटेक्स अधिक कुशल होगा। इस समस्या के बारे में जागरूकता तुरंत नहीं आई, और समाधान बहुत आसान है - जब संकलन करते हैं, तो हम कनेक्शन की अपेक्षित संख्या के बराबर BOOST_ASIO_ENABLE_SEQUENTIAL_STRAND_ALLOCATION और BOOST_ASIO_STRAND_IMOCEMENTATIONS डालते हैं। किसी कारण के लिए, इस तरह की सुविधा को कहीं भी प्रलेखित नहीं किया गया है, केवल स्ट्रैंड_ सर्विस कोड को छोड़कर। बेशक, यदि उपयोग किए गए सभी प्रोटोकॉल गैर-अवरुद्ध हैं और एप्लिकेशन सत्य-असिंक्रोनस है, तो यह समस्या प्रासंगिक होने की संभावना नहीं है, लेकिन हमारे मामले में ब्लॉकिंग मोड में काम कर रहे लाइब्रेरी हैं, इसलिए (अभी के लिए) आपको वर्कअराउंड को देखना होगा।

बफ़र्स पढ़ने / लिखने से संबंधित कुछ विशेषताएं भी हैं। यदि आप asio :: streambuf का उपयोग करते हैं, तो आपको यह समझने की आवश्यकता है कि यह बफ़र मेमोरी देना पसंद नहीं करता है - आपको इसके साथ रेकॉर्ड करना होगा और कुछ वर्कअराउंड करने होंगे। कुछ हद तक निराशा होती है कि कोई भी मूल प्रतिस्पर्धी लेखन बफर नहीं है। हमारे IProto जैसे प्रोटोकॉल के लिए, यह एक बहुत ही उपयोगी विशेषता होगी - प्रोटोकॉल का अर्थ है बड़ी संख्या में छोटे पैकेट। एक और नुकसान यह है कि सॉकेट को लिखते समय आरसी के खिलाफ कोई सुरक्षा नहीं है, इसलिए आपको एसएसएल मोड में समानांतर async_write नहीं करना चाहिए (और सामान्य में भी!)। इसके अलावा, रिकॉर्डिंग बफ़र्स को स्विच करने के लिए एक कतार, या एक तंत्र को व्यवस्थित करना आवश्यक है, या बस किसी तरह समानांतर कॉल को रोकना है। और यहां फिर से, अतिरिक्त समस्याएं उत्पन्न होती हैं: यदि सहकर्मी गायब हो जाता है, तो लेखन बफ़र तब तक बढ़ सकता है जब तक कि वर्तमान async_write समझता है कि कोई और सहकर्मी नहीं है। यह आपकी स्मृति को खा सकता है, जो निश्चित रूप से फिर से अधिकतम खुले कनेक्शन को प्रभावित करेगा।

शायद यह कई लोगों के लिए एक स्पष्ट तथ्य है, लेकिन फिर भी मैं इसे अलग से जोर देना चाहूंगा: 10 हजार कनेक्शन "आउट" किसी भी आंतरिक सेवा पर 10 हजार कनेक्शन के समान नहीं है, जहां केवल "आपके" लोग जाते हैं । पहले मामले में, बस अविश्वसनीय चीजें हो सकती हैं, जिसके खिलाफ लड़ाई सबसे बड़ी कठिनाई है। ये वे विचित्र ग्राहक हो सकते हैं जो एसएसएल हैंडशेक पूरा करने से पहले डिस्कनेक्ट कर देते हैं। यह बहुत धीमी गति से हो सकता है, जो आपको 256 केबीपीएस की गति से 40 एमबी पत्र डाउनलोड करता है। यह सरल लगता है, लेकिन APPEND कमांड अक्षर के शरीर को शाब्दिक रूप में स्वीकार करता है; इसका मतलब यह है कि जब तक पत्र डाउनलोड नहीं किया गया है, तब तक आदेश जारी नहीं किया गया है और किसी न किसी तरह स्मृति में होना चाहिए, और, जैसा कि आप जानते हैं, स्मृति रबर नहीं है। FETCH कमांड के मामले में, विपरीत सच है: यदि क्लाइंट की रिसेप्शन की गति धीमी है और आप 1 एमबी भेजना चाहते हैं, तो डेटा का यह टुकड़ा आपकी मेमोरी में तब तक है जब तक इसे भेजा नहीं जाता।

इसलिए, यदि आपकी सेवा "बाहर" दिखती है, तो आपको बहुत सारे कारकों पर विचार करने की आवश्यकता है। असियो की तरह साबित हुई लाइब्रेरियाँ आप से बहुत सारी समस्याओं को दूर करती हैं जिनके बारे में आप केवल "लड़ाई में" सीख सकते हैं।

निष्कर्ष, सर्वर विकास योजनाएं

सामान्य तौर पर, हम संतुष्ट हैं। सेवा अधिक स्थिर काम करने लगी, अधिक कनेक्शन संभालती है, बहुत कम दुर्घटनाग्रस्त होती है।
सर्वर का आगे विकास अपरिहार्य है - हम स्थिरता में सुधार करने के लिए, आईडीएल सहित आरएफसी एक्सटेंशन के लिए समर्थन का विस्तार करने की योजना बना रहे हैं; मुझे लगता है कि बढ़ावा :: asio आसानी से हमें इस के साथ मदद मिलेगी। यह कल्पना करना अभी भी मुश्किल है कि एक ही समय में आईडीएलई राज्य में कितने कनेक्शन हो सकते हैं, लेकिन, मुझे विश्वास है, बहुत कुछ। शायद इसका प्रभाव इतना महान नहीं होगा, क्योंकि कई मोबाइल ग्राहक (और अब उनमें से ज्यादातर) आईडीएलई को नहीं जानते हैं। लेकिन यह asio पर करना बहुत सरल होगा, इसलिए IMAP सर्वर की ओर से यह एक जटिल शोधन नहीं है।
इसके अलावा, नई आंतरिक सेवाएं आ रही हैं, जो स्वाभाविक रूप से अतुल्यकालिक हैं, और उनके साथ संचार हमारे पसंदीदा IProto प्रोटोकॉल के अनुसार होता है, जो कम अवरोधन की अनुमति देगा और इसलिए, प्रसंस्करण अनुरोधों को तेजी से बढ़ाता है।

एक सवाल है? पूछो! एक उपयोगी कार्यान्वयन अनुभव है? टिप्पणियों में साझा करें!

अल्बर्ट गैलिमोव,

मेल डेवलपमेंट बैकएंड ग्रुप प्रोग्रामर