शुभ दोपहर, साथियों!

आज मैं आपको बताऊंगा कि, आवेदन में बड़ी संख्या में बदलाव किए बिना, इसके प्रदर्शन में सुधार कैसे किया जाए। यह हमारे छोटे "साइकिल" [1] के बारे में होगा, जिसे कुछ मामलों में मेमकेच को बदलने के लिए डिज़ाइन किया गया है।

यह लेख मेरी रिपोर्ट में लिखा गया था, " देवकोनफ '12 पर " लगभग धोखा दे रहा है या गैर-मानक चीजों के लिए मानक प्रोटोकॉल का उपयोग कर रहा है " [2]।

परिचय

हमने हाल ही में Plus1 WAPStart मोबाइल विज्ञापन नेटवर्क की वास्तुकला के बारे में बात की है। यदि आपने नहीं पढ़ा है, तो आप लिंक पढ़ सकते हैं।

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

एक बैनर चुनने के तर्क को 3 चरणों में विभाजित किया जा सकता है:

1. अनुरोध की विशेषताओं का निर्धारण।
2. अनुरोध के लिए उपयुक्त बैनरों का चयन।
3. कटऑफ रनटाइम पर।

चरण संख्या 1 हमारे लिए समस्याग्रस्त हो गया। इसके अलावा, परेशानी वहाँ से आई जहाँ वे प्रतीक्षा नहीं करते थे

आमतौर पर, अनुरोध की विशेषताओं को निर्धारित करने के लिए आवश्यक सभी डेटा कैश में होते हैं, और केवल कुछ प्रतिशत अनुरोध डेटाबेस में होते हैं।


लेकिन जब भारत हमारे पास आता है, तब हमारे पास कैश में कुछ भी नहीं होता है और 70-90% अनुरोध डेटाबेस में जाते हैं। यह कुछ समस्याओं का कारण बनता है और हम बैनर को थोड़ा धीमा कर देते हैं जितना हम चाहते हैं।


और फिर हमें एक विचार मिला कि बैनर रिटर्न स्पीड की समस्या को कैसे हल किया जाए।

परियोजना "मछली": एक विचार

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

इस तथ्य के कारण कि हम कैशिंग के लिए मेम्के का उपयोग करते हैं, संकेतित विचार को लागू करने के लिए इसके प्रोटोकॉल का उपयोग करने का निर्णय लिया गया था।

प्रोजेक्ट "मछली": पहला पुनरावृत्ति

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

पुस्तकालय कोई भी हो सकता है। हमारे मामले में, यह डेटाबेस से डेटा का अनुरोध करता है।

हमने एप्लिकेशन लॉजिक को बदल दिया है ताकि अनुरोध की विशेषताओं को हमारे कैश से लिया जाए (अनुरोध से एक कुंजी बनती है और हम key_with_request_characteristics प्राप्त करने के लिए कहते हैं )। इस विन्यास में, कुछ मुद्दों को छोड़कर सब कुछ ठीक रहा।

समस्याएं और उनका समाधान

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

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

परियोजना "मछली": दूसरा पुनरावृत्ति

सामान्य तौर पर, चित्र एक ही रहा , दो कार्यात्मक इकाइयों के अपवाद के साथ जो हमने पुस्तकालय में जोड़ा।

पहला नॉर्मलाइज़र है । हम सभी प्रश्नों को सामान्य करते हैं (हम मानक रूप में लाते हैं)। और स्टोर में हम पहले से ही सामान्यीकृत कुंजी पर डेटा की तलाश कर रहे हैं।

जैसा कि मैंने ऊपर लिखा है, अनुरोध से एक कुंजी उत्पन्न होती है। कुंजी यह समग्र है। खुद के लिए, हमने लेक्सिकोग्राफ़िक क्रम में इस कुंजी के हिस्सों को क्रमबद्ध करने का निर्णय लिया।

दूसरा है हशेर । यह डेटा की तुलना करने के लिए कार्य करता है। अब हम एक ही डेटा को दो बार स्टोरेज में नहीं जोड़ते हैं।

यदि पहले हमने एक कुंजी-मूल्य जोड़ी जमा की थी, तो अब हम कुंजी और डेटा को अलग-अलग संग्रहीत करते हैं। चाबियाँ और डेटा के बीच एक-से-कई संबंध हैं (एक डेटा कई कुंजी के अनुरूप हो सकता है)।

और फिर, सब कुछ ठीक लग रहा है, लेकिन फिर से हमें डेटा हटाने की समस्या का सामना करना पड़ा।

समस्याएं और उनका समाधान

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

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

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

हटाने की समस्या के अलावा, अभी भी "पहली अनुरोध समस्या" है - जब कोई डेटा नहीं होता है तो हम एक खाली अनुरोध के साथ प्रतिक्रिया करते हैं। यह पहले संस्करण से है, लेकिन हमारे लिए यह अनुमेय है और निकट भविष्य में हम इसे हल करने की योजना नहीं बनाते हैं।

निष्कर्ष

हमारे लिए, लड़ाई में "मछली" की शुरूआत ने हमें कोड को फिर से लिखने की लागत को कम करने की अनुमति दी। एप्लिकेशन लॉजिक में बहुत बदलाव नहीं हुआ है, हम अभी-अभी एक और कैश को अपवित्र करने लगे हैं। और अब दुर्लभ अनुरोधों के मामले में, हम जल्दी और आत्मविश्वास से जवाब देते हैं।

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

संदर्भ

1. परियोजना "मछली"
2. रिपोर्ट प्रस्तुत करना
3. गपशप गथब