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

हमने हाल ही में एक एकल सेवा के प्रदर्शन में नाटकीय रूप से सुधार किया, इसे गो टू रस्ट से पुनर्लेखन किया। यह लेख बताएगा कि इस सेवा को फिर से लिखने के लिए हमारे लिए यह समझ में क्यों आया, हमने इसे कैसे किया और उत्पादकता में कितना सुधार हुआ।

राज्य ट्रैकिंग सेवा पढ़ें (राज्यों को पढ़ें)

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

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

हमारे प्रदर्शन लक्ष्यों को पूरा क्यों नहीं किया जाता है

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

राज्य की जानकारी संग्रहीत करने के लिए, हम एक डेटा संरचना का उपयोग करते हैं, जिसे कहा जाता है: पढ़ें राज्य। डिस्कॉर्ड में उनके अरबों हैं: प्रत्येक चैनल प्रति उपयोगकर्ता के लिए एक राज्य। प्रत्येक राज्य में कई काउंटर हैं, जिन्हें परमाणु रूप से अद्यतन किया जाना चाहिए और अक्सर शून्य पर रीसेट किया जाना चाहिए। उदाहरण के लिए, काउंटरों @mentionमें से एक चैनल में संख्या है।

परमाणु काउंटर को जल्दी से अपडेट करने के लिए, प्रत्येक रीड स्टेट्स सर्वर में कम से कम हाल ही में प्रयुक्त (LRU) कैश होता है। प्रत्येक कैश में लाखों उपयोगकर्ता और दसियों लाख राज्य हैं। कैश को प्रति सेकंड सैकड़ों बार अपडेट किया जाता है।

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

नीचे दिया गया ग्राफ़ गो ¹ सेवा के लिए पीक टाइम अंतराल पर प्रतिक्रिया समय और सीपीयू लोड दिखाता है । यह देखा जा सकता है कि सीपीयू पर लोड की देरी और फटने लगभग हर दो मिनट में होते हैं।

तो हर दो मिनट में देरी की वृद्धि कहाँ है?

जब कैश को कुंजी से बाहर धकेला जाता है, तो गो को मेमोरी तुरंत मुक्त नहीं किया जाता है। इसके बजाय, कचरा कलेक्टर समय-समय पर चलता है और स्मृति के अप्रयुक्त भागों की तलाश करता है। यह बहुत काम है जो एक कार्यक्रम को धीमा कर सकता है।

यह बहुत संभव है कि हमारी सेवा की आवधिक मंदी कचरा संग्रहण से जुड़ी हो। लेकिन हमने स्मृति आवंटन की एक न्यूनतम राशि के साथ एक बहुत ही कुशल गो कोड लिखा। ज्यादा कचरा नहीं छोड़ना चाहिए। बात क्या है?

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

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

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

और इसलिए यह हुआ। छोटे कैश के साथ, शिखर देरी कम हो जाती है।

दुर्भाग्य से, कम LRU कैश के साथ समझौता ने 99 वाँ प्रतिशत बढ़ाया (यानी, 99% देरी के नमूने का औसत मूल्य, शिखर वाले लोगों को छोड़कर) बढ़ा। ऐसा इसलिए है क्योंकि कैश कम होने से उपयोगकर्ता के रीड स्टेट कैश में होने की संभावना कम हो जाती है। यदि यह यहां नहीं है, तो हमें डेटाबेस की ओर मुड़ना चाहिए।

विभिन्न कैश आकारों पर लोड परीक्षण की एक बड़ी मात्रा के बाद, हमें एक स्वीकार्य सेटिंग मिली। हालांकि आदर्श नहीं, यह एक संतोषजनक समाधान था, इसलिए हमने इस तरह से काम करने के लिए लंबे समय तक सेवा छोड़ दी।

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

स्मृति प्रबंधन जंग में

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

जंग में कूड़ा उठाने वाला नहीं है, इसलिए हमने फैसला किया कि गो जैसी कोई देरी नहीं होगी।

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

इस प्रकार, रस्ट संस्करण में, जब रीड स्टेट को LRU कैश से बाहर रखा जाता है, तो मेमोरी को तुरंत मुक्त कर दिया जाता है। यह मेमोरी नहीं बैठती है और कचरा कलेक्टर के लिए इंतजार नहीं करता है। जंग को पता है कि यह अब उपयोग में नहीं है और तुरंत इसे जारी करता है। किस मेमोरी को फ्री में स्कैन करने के लिए रनटाइम में कोई प्रक्रिया नहीं है।

अतुल्यकालिक जंग

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

सौभाग्य से, रस्ट टीम ने अतुल्यकालिक प्रोग्रामिंग को सरल बनाने के लिए कड़ी मेहनत की, और यह अस्थिर चैनल (नाइटी) पर पहले से ही उपलब्ध था।

होनहार नई तकनीकों को सीखने से कभी नहीं डरते थे। उदाहरण के लिए, हम अमृत, रिएक्ट, रिएक्टिव नेटिव और स्केला के पहले उपयोगकर्ताओं में से एक थे। अगर कुछ तकनीक आशाजनक दिखती है और हमें फायदा देती है, तो हम कार्यान्वयन की अपरिहार्य कठिनाई और उन्नत उपकरणों की अस्थिरता का सामना करने के लिए तैयार हैं। यह एक कारण है कि हम राज्य में 50 से कम प्रोग्रामर के साथ 250 मिलियन उपयोगकर्ताओं के दर्शकों तक इतनी जल्दी पहुंच गए हैं।

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

कार्यान्वयन, तनाव परीक्षण और प्रक्षेपण

कोड को फिर से लिखना आसान था। हमने एक मोटे प्रसारण के साथ शुरुआत की, फिर इसे उन जगहों पर कम कर दिया जहां यह समझ में आया। उदाहरण के लिए, रस्ट में जेनेरिक के लिए व्यापक समर्थन के साथ एक उत्कृष्ट प्रकार की प्रणाली है (किसी भी प्रकार के डेटा के साथ काम करने के लिए), इसलिए हमने चुपचाप गो कोड को फेंक दिया, जिसने जेनरिक की कमी की भरपाई की। इसके अलावा, रस्ट मेमोरी मॉडल विभिन्न थ्रेड्स में मेमोरी सुरक्षा को ध्यान में रखता है, इसलिए हमने सुरक्षात्मक गोरोइटिन को फेंक दिया।

लोड परीक्षण ने तुरंत एक उत्कृष्ट परिणाम दिखाया। रस्ट पर सेवा प्रदर्शन गो संस्करण के रूप में उच्च के रूप में निकला, लेकिन इन देरी के फटने के बिना !

आमतौर पर, हमने व्यावहारिक रूप से जंग संस्करण का अनुकूलन नहीं किया। लेकिन यहां तक कि सबसे सरल अनुकूलन के साथ, रस्ट गो के सावधानीपूर्वक ट्यून किए गए संस्करण को बेहतर बनाने में सक्षम था।गो में गहरे जाने की तुलना में प्रभावी रस्ट कार्यक्रमों को लिखना कितना आसान है, इसका यह एक स्पष्ट प्रमाण है।

लेकिन हमने साधारण प्रदर्शन को संतुष्ट नहीं किया। थोड़ा रूपरेखा और अनुकूलन के बाद, हमने सभी मामलों में गो को पीछे छोड़ दिया । देरी, सीपीयू और मेमोरी - रस्ट संस्करण में सब कुछ बेहतर हो गया।

जंग प्रदर्शन अनुकूलन शामिल हैं:

स्मृति उपयोग को अनुकूलित करने के लिए LRU कैश में HashMap के बजाय BTreeMap पर स्विच करना।
आधुनिक संगामिति जंग के समर्थन के साथ एक संस्करण के साथ मैट्रिक्स की मूल लाइब्रेरी की जगह।
मेमोरी में प्रतियों की संख्या घटाएं।

संतुष्ट होकर, हमने सेवा को तैनात करने का निर्णय लिया।

प्रक्षेपण काफी सुचारू रूप से चला, क्योंकि हमने तनाव परीक्षण किया। हमने सेवा को एक परीक्षण नोड से जोड़ा, खोजा और कई सीमावर्ती मामलों को तय किया। इसके तुरंत बाद, उन्होंने पूरे सर्वर पार्क में एक नया संस्करण शुरू किया।

परिणाम नीचे दर्शाए गए है।

बैंगनी ग्राफ गो है, नीला ग्राफ Rust है।

कैश आकार बढ़ाएँ

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

नीचे दिए गए परिणाम अपने लिए बोलते हैं। ध्यान दें कि औसत समय अब माइक्रोसेकंड में मापा जाता है, और अधिकतम देरी @mentionको मिलीसेकंड में मापा जाता है।

पारिस्थितिकी तंत्र का विकास

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

अंतिम विचार

डिस्कोर्ड वर्तमान में सॉफ्टवेयर स्टैक के कई हिस्सों में रस्ट का उपयोग करता है: गेमएसडीके के लिए, गो लाइव, एलिक्सिर एनआईएफ , कई बैकएंड सेवाओं और बहुत अधिक में वीडियो कैप्चरिंग और एन्कोडिंग ।

एक नई परियोजना या सॉफ्टवेयर घटक शुरू करते समय, हम निश्चित रूप से जंग का उपयोग करने पर विचार कर रहे हैं। बेशक, केवल जहां यह समझ में आता है।

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

मजेदार तथ्य: रस्ट टीम भी समन्वय करने के लिए डिस्कॉर्ड का उपयोग करती है। यहां तक कि बहुत उपयोगी भी हैजंग सामुदायिक सर्वर , जहां हम कभी-कभी चैट करते हैं।

फुटनोट

गो संस्करण 1.9.2 से लिया गया चार्ट। हमने बिना किसी सुधार के 1.8, 1.9 और 1.10 संस्करणों की कोशिश की। गो टू रस्ट से प्रारंभिक प्रवास मई 2019 में पूरा हुआ। [लौटने के लिये]
स्पष्टता के लिए, हम बिना किसी कारण के रस्ट में सब कुछ फिर से लिखने की सलाह नहीं देते हैं। [लौटने के लिये]
आधिकारिक साइट से उद्धरण। [लौटने के लिये]
बेशक, जब तक आप असुरक्षित का उपयोग नहीं करते हैं । [लौटने के लिये]

क्यों कलह से पलायन रुकावट को दूर करता है