बवंडर बनाम Aiohttp: अतुल्यकालिक चौखटे के wilds में एक यात्रा

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



जैसा कि आप जानते हैं, एविटो एक काफी बड़ी विज्ञापन सेवा है। हमारे पास बहुत अधिक डेटा और लोड है, हर महीने 35 मिलियन उपयोगकर्ता और दैनिक 45 मिलियन सक्रिय विज्ञापन हैं। मैं एक सिफारिश विकास समूह के तकनीकी सलाहकार के रूप में काम करता हूं। मेरी टीम माइक्रोसर्विसेज लिखती है, अब हमारे पास उनमें से लगभग बीस हैं। एक लोड इस सब पर जमा है - जैसे 5k आरपीएस।

एक एसिंक्रोनस फ्रेमवर्क चुनना

पहले मैं आपको बताऊंगा कि हम अब कहाँ हैं, हम कैसे समाप्त हुए। 2015 में, हमें एक अतुल्यकालिक ढांचे को चुनने की आवश्यकता थी, क्योंकि हम जानते थे:

• कि आप अन्य microservices के लिए बहुत अनुरोध करना होगा: http, json, rpc;
• आपको हर समय विभिन्न स्रोतों से डेटा एकत्र करने की आवश्यकता होगी: Redis, Postgres, MongoDB।

इस प्रकार, हमारे पास बहुत सारे नेटवर्क कार्य हैं, और एप्लिकेशन का मुख्य रूप से इनपुट / आउटपुट के साथ कब्जा है। उस समय अजगर का वर्तमान संस्करण 3.4 था, async और इंतजार अभी तक प्रकट नहीं हुआ था। Aiohttp भी था - संस्करण 0.x में। फेसबुक का एसिंक्रोनस टॉरनेडो 2010 में दिखाई दिया। बहुत सारे डेटाबेस ड्राइवर उसके लिए लिखे गए हैं जिनकी हमें आवश्यकता है। बवंडर ने बेंचमार्क पर स्थिर परिणाम दिखाए। फिर हमने इस ढांचे पर अपनी पसंद को रोक दिया।

तीन साल बाद, हमने बहुत कुछ समझा।

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

पाइकॉन रूस 2018 में अपनी बात करते हुए, आंद्रेई श्वेतलोव ने कहा: "यदि आप किसी प्रकार के अतुल्यकालिक वेब एप्लिकेशन को लिखना चाहते हैं, तो कृपया सिर्फ एसिंक्रोनस लिखें, प्रतीक्षा करें। इवेंट लूप, शायद, आपको जल्द ही इसकी आवश्यकता नहीं होगी। चौखटों के चक्कर में न पड़ें ताकि भ्रमित न हों। निम्न-स्तर की प्राथमिकताओं का उपयोग न करें, और आपके साथ सबकुछ ठीक हो जाएगा ... "। पिछले तीन वर्षों में, हम, दुर्भाग्य से, बहुत बार टॉरनेडो के अंदर चढ़ गए, वहां से बहुत सारी दिलचस्प चीजें सीखीं और 30-40 कॉल के लिए विशाल ट्रेसबैक देखे।

से उपज बनाम उपज

अतुल्यकालिक अजगर में समझने के लिए सबसे बड़ी समस्याओं में से उपज और उपज के बीच का अंतर है।

Guido Van Rossum ने इसके बारे में और लिखा है । मैं अनुवाद को थोड़े संक्षिप्त रूप में संलग्न कर रहा हूं।

मुझे कई बार पूछा गया है कि पीईपी 3156 पैदावार के बजाय उपज का उपयोग करने पर जोर देता है, जो कि पायथन 3.2 या 2.7 में बैकपोर्टिंग की संभावना को बाहर करता है।
(...)
जब भी आपको भविष्य का परिणाम चाहिए, आप उपज का उपयोग करें।
इसे निम्नानुसार कार्यान्वित किया जाता है। उपज युक्त फ़ंक्शन (स्पष्ट रूप से) एक जनरेटर है, इसलिए किसी प्रकार का पुनरावृत्त कोड होना चाहिए। चलो उसे एक योजनाकार कहते हैं। वास्तव में, अनुसूचक शास्त्रीय अर्थ में "forerate" नहीं करता (लूप के लिए); इसके बजाय, यह भविष्य के दो संग्रहों का समर्थन करता है।

मैं पहले संग्रह को "निष्पादन योग्य" अनुक्रम कहूंगा। यह भविष्य है, जिसके परिणाम उपलब्ध हैं। हालांकि यह सूची खाली नहीं है, लेकिन अनुसूचक एक आइटम का चयन करता है और एक पुनरावृत्ति कदम उठाता है। यह चरण भविष्य से परिणाम के साथ .send () जनरेटर विधि को कॉल करता है (जो डेटा हो सकता है जिसे केवल सॉकेट से पढ़ा गया है); जनरेटर में, यह परिणाम उपज अभिव्यक्ति के वापसी मूल्य के रूप में प्रकट होता है। जब भेजें () एक परिणाम लौटाता है या पूरा होता है, तो शेड्यूलर परिणाम को रोक देता है (जो स्टॉपइटरेशन, एक अन्य अपवाद या किसी प्रकार की वस्तु हो सकती है)।
(यदि आप भ्रमित हैं, तो आपको संभवतः जनरेटर कैसे काम करता है, इसके बारे में पढ़ना चाहिए। विशेष रूप से .send () विधि। शायद PEP 342 एक अच्छा प्रारंभिक बिंदु है)।

(...)

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

(...)

अब हम सबसे दिलचस्प तक पहुंच गए हैं। मान लीजिए आप एक जटिल प्रोटोकॉल लिख रहे हैं। अपने प्रोटोकॉल के अंदर, आप रीव () विधि का उपयोग करके सॉकेट से बाइट्स पढ़ते हैं। ये बाइट्स बफ़र के लिए मिलते हैं। आरईवीवी () पद्धति को एक एसिंक्श शेल में लपेटा गया है, जो I / O सेट करता है और भविष्य को लौटाता है, जिसे I / O पूरा होने पर निष्पादित किया जाता है, जैसा कि मैंने ऊपर बताया। अब मान लीजिए कि आपके कोड का कोई दूसरा भाग बफर लाइन के डेटा को एक बार में पढ़ना चाहता है। मान लीजिए आपने रीडलाइन () पद्धति का उपयोग किया है। यदि बफ़र का आकार औसत लाइन की लंबाई से बड़ा है, तो आपकी रीडलाइन () विधि बफ़र से अगली पंक्ति को बिना अवरुद्ध किए प्राप्त कर सकती है; लेकिन कभी-कभी बफर में एक पूरी रेखा नहीं होती है, और सॉकेट पर रीडलाइन () बदले में कॉल (आरईवी) फिर से शुरू होती है।

प्रश्न: रीडलाइन () भविष्य में लौटना चाहिए या नहीं? यह बहुत अच्छा नहीं होगा यदि वह कभी-कभी एक बाइट स्ट्रिंग लौटाता है, और कभी-कभी भविष्य में, कॉलर को टाइप चेकिंग और सशर्त उपज देने के लिए मजबूर करता है। तो इसका उत्तर यह है कि रीडलाइन () को हमेशा भविष्य में लौटना चाहिए। जब रीडलाइन () कहा जाता है, तो यह बफर की जांच करता है, और अगर यह वहां कम से कम एक पूरी लाइन पाता है, तो यह भविष्य बनाता है, बफर से ली गई रेखा के भविष्य के परिणाम को सेट करता है, और भविष्य में वापस आता है। यदि बफ़र में पूरी रेखा नहीं है, तो यह I / O आरंभ करता है और यह अपेक्षा करता है, और जब I / O पूरा हो जाता है, तो यह नए सिरे से शुरू होता है।

(...)

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

(...)

इस सब का शुद्ध प्रभाव यह है कि कोरटाइन लेखकों को उपज के भविष्य के बारे में जानने की जरूरत है, और इसलिए जटिल कोड को अधिक पठनीय कोरटाइन में पुनर्गठित करने के लिए एक बड़ा मनोवैज्ञानिक अवरोध है - मौजूदा प्रतिरोध की तुलना में बहुत मजबूत, क्योंकि पायथन में फ़ंक्शन कॉल बहुत धीमा है। और मुझे ग्लिफ़ के साथ एक बातचीत से याद है कि गति एक विशिष्ट अतुल्यकालिक I / O संरचना में महत्वपूर्ण है।
अब इसे उपज से तुलना करते हैं।

(...)

आपने सुना होगा कि "एस से उपज" लगभग "एस में मैं के लिए: उपज मैं" के बराबर है। सबसे सरल मामले में, यह सच है, लेकिन यह कोरटाइन को समझने के लिए पर्याप्त नहीं है। निम्नलिखित पर विचार करें (अभी तक I / O के बारे में मत सोचो):

def driver(g): print(next(g)) g.send(42) def gen1(): val = yield 'okay' print(val) driver(gen1()) 

यह कोड "ओके" और "42" वाली दो पंक्तियों को प्रिंट करता है (और फिर एक बिना रुके स्टॉपइंटरेशन पैदा करता है, जिसे आप जीन 1 के अंत में उपज जोड़कर दबा सकते हैं)। आप इस कोड को लिंक पर pythontutor.com पर कार्रवाई में देख सकते हैं।

अब निम्नलिखित पर विचार करें:

 def gen2(): yield from gen1() driver(gen2()) 

यह ठीक उसी तरह काम करता है। अब सोचिये। यह कैसे काम करता है? फॉर-लूप में साधारण उपज-विस्तार का उपयोग यहां नहीं किया जा सकता है, क्योंकि इस मामले में कोड कोई भी नहीं लौटेगा। (यह कोशिश करो) । यील्ड-ड्राइवर और जीन 1 के बीच "पारदर्शी चैनल" के रूप में कार्य करता है। यही है, जब जीन 1 मान देता है "ठीक है", यह जीन 2 से बाहर निकलता है, उपज-से, ड्राइवर को, और जब ड्राइवर 42 को वापस जीन 2 में भेजता है, तो यह मान उपज से वापस-से वापस जीन 1 तक पहुंच जाता है (जहां यह उपज का परिणाम बन जाता है) )।

यदि ड्राइवर जनरेटर में कोई त्रुटि देता है तो यही बात होगी: त्रुटि उपज से-उस आंतरिक जनरेटर तक जाती है जो इसे संसाधित करती है। उदाहरण के लिए:

 def throwing_driver(g): print(next(g)) g.throw(RuntimeError('booh')) def gen1(): try: val = yield 'okay' except RuntimeError as exc: print(exc) else: print(val) yield throwing_driver(gen1()) 

कोड "ठीक" और "बाह" देगा, साथ ही साथ निम्नलिखित कोड:

 def gen2(): yield from gen1() # unchanged throwing_driver(gen2()) 

(यहां देखें: goo.gl/8tnjk )

अब मैं इस तरह के कोड के बारे में बात करने में सक्षम होने के लिए सरल (एएससीआईआई) ग्राफिक्स शुरू करना चाहूंगा। मैं [f1 -> f2 -> ... -> fN) का उपयोग शीर्ष पर f1 (सबसे पुराना कॉल फ्रेम) और fN के साथ स्टैक को दर्शाने के लिए करता हूं (सबसे नया कॉल फ्रेम), जहां सूची में प्रत्येक आइटम एक जनरेटर है, और ->> उपज-से । पहला उदाहरण, ड्राइवर (gen1 ()) की उपज-से नहीं है, लेकिन इसमें एक जीन 1 जनरेटर है, इसलिए यह इस तरह दिखता है:

 [ gen1 ) 

दूसरे उदाहरण में, gen2 उपज से जीन 1 का उपयोग करता है, इसलिए ऐसा दिखता है:

 [ gen2 -> gen1 ) 

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

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

 [ app -> readline -> read -> recv ) 

अब आरईवीवी () जनरेटर I / O सेट करता है, इसे भविष्य में बांधता है, और इसे शेड्यूलर को * उपज * (उपज-नहीं!) का उपयोग करके पास करता है। भविष्य शेड्यूलर में उपज-दोनों तीरों के साथ बाईं ओर जाता है ("[" के बाईं ओर स्थित है)। ध्यान दें कि अनुसूचक को पता नहीं है कि इसमें जनरेटर का एक ढेर शामिल है; वह जानता है कि उसके पास सबसे बायां जनरेटर है और उसने अभी-अभी भविष्य जारी किया है। जब I / O पूरा हो जाता है, तो शेड्यूलर भविष्य का परिणाम निर्धारित करता है और इसे जनरेटर को वापस भेजता है; परिणाम दोनों येल्ड-से एरो के साथ दाईं ओर ले जाता है, जो कि आरवी जनरेटर को प्राप्त होता है, जो बाइट्स को प्राप्त करता है जो इसे सॉकेट से उपज परिणाम के रूप में पढ़ना चाहता था।

दूसरे शब्दों में, पैदावार-से-फ्रेमवर्क शेड्यूलर I / O संचालन को उसी तरह से हैंडल करता है जैसे कि पहले बताए गए यील्ड-आधारित फ्रेमवर्क शेड्यूलर। * लेकिन * * भविष्य के पहले से ही निष्पादित होने पर उसे अनुकूलन के बारे में चिंता करने की ज़रूरत नहीं है, क्योंकि शेड्यूलर रीडलाइन () और रीड () के बीच या रीड () और रिकव (), और इसके विपरीत के बीच नियंत्रण के हस्तांतरण में भाग नहीं लेता है। इसलिए, शेड्यूलर तब भाग नहीं लेता है जब एप्लिकेशन () कॉल रीडलाइन (), और रीडलाइन () कॉल (रीड कॉलिंग के बिना) से अनुरोध को पूरा कर सकता है - (ऐप और) और रीडलाइन () के बीच की बातचीत इस मामले में पूरी तरह से बायटेकोड दुभाषिया द्वारा संसाधित होती है अजगर। शेड्यूलर सरल हो सकता है, और शेड्यूलर द्वारा बनाए गए और प्रबंधित भविष्य की संख्या कम है, क्योंकि कोई भविष्य नहीं है जो कोरटाइन के हर कॉल के साथ बनाया और नष्ट किया जाता है। एकमात्र भविष्य जो अभी भी आवश्यक है, वे वास्तविक I / O का प्रतिनिधित्व करते हैं, उदाहरण के लिए, recv () द्वारा निर्मित।

यदि आप इस बिंदु तक पढ़ चुके हैं, तो आप पुरस्कार के पात्र हैं। मैंने कई कार्यान्वयन विवरणों को छोड़ दिया, लेकिन उपरोक्त चित्र अनिवार्य रूप से चित्र को सही ढंग से दर्शाता है।

एक और बात मैं बताना चाहूंगा। * आप कोड का उपयोग उपज से हिस्सा बना सकते हैं, और दूसरा हिस्सा उपज का उपयोग कर सकते हैं। लेकिन पैदावार के लिए जरूरी है कि श्रृंखला के हर लिंक का भविष्य हो, न कि सिर्फ कोरटाइन। चूंकि उपज का उपयोग करने के कई फायदे हैं, इसलिए मैं चाहता हूं कि उपयोगकर्ता को यह याद नहीं रखना चाहिए कि उपज का उपयोग कब करना है, और उपज-से, यह हमेशा उपज से उपयोग करना आसान है। एक सरल समाधान भी पुनरावर्ती () उपज का उपयोग करने के लिए-से भविष्य के I / O को अनुसूचक को पास करने की अनुमति देता है: __iter__ विधि वास्तव में जनरेटर है जो भविष्य का मुद्दा है।

(...)

और एक बात। उपज-वापसी से क्या मूल्य है? यह पता चला है कि यह * बाहरी * जनरेटर का रिटर्न वैल्यू है।

(...)

इस प्रकार, जबकि तीर बाएँ और दाएँ फ्रेम को * उपज * लक्ष्य पर बाँधते हैं, वे सामान्य रिटर्न मान भी सामान्य तरीके से पास करते हैं, एक समय में एक स्टैक फ्रेम। अपवादों को उसी तरह से स्थानांतरित किया जाता है; बेशक, प्रत्येक स्तर पर, उन्हें पकड़ने के लिए प्रयास करना / छोड़ना आवश्यक है।

पैदावार से बाहर निकला जाता है बहुत इंतजार के रूप में ही है।

बनाम async से उपज

def कोरो () ^ y = से उपज	async def async_coro (): y = a का इंतजार है
0 load_global	0 load_global
2 get_yield_from_iter	2 get_awaitable
4 load_const	4 load_const
6 उपज_फ्रॉम	6 उपज_फ्रॉम
8 store_fast	8 store_fast
10 load_const	10 load_const
12 रिटर्न_वल्यू	12 रिटर्न_वल्यू

पुराने और नए स्कूलों के दो कॉरआउट्स में केवल एक ही मामूली अंतर है - पुनरावृत्ति से उपज प्राप्त होती है।

यह सब क्यों है? बवंडर एक साधारण उपज का उपयोग करता है। संस्करण 5 से पहले, यह पैदावार के माध्यम से कॉल की इस पूरी श्रृंखला को जोड़ता है, जो / शांत प्रतिमान से नए शांत उपज के साथ खराब रूप से संगत है।

सबसे सरल अतुल्यकालिक बेंचमार्क

वास्तव में अच्छा ढांचा ढूंढना मुश्किल है, केवल सिंथेटिक परीक्षणों के अनुसार इसे चुनना। वास्तविक जीवन में, बहुत सारी चीजें गलत हो सकती हैं।

मैंने Aiohttp संस्करण 3.4.4, Tornado 5.1.1, uvloop 0.11 लिया, Intel Xeon सर्वर प्रोसेसर, CPU E5 v4, 3.6 GHz लिया और इस पर Python 3.6.5 के साथ मैंने प्रतिस्पर्धा के लिए वेब सर्वरों की जाँच शुरू कर दी।

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

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

 @tornado.gen.coroutine def old_school_work(): yield tornado.gen.sleep(SLEEP_TIME) async def work(): await tornado.gen.sleep(SLEEP_TIME) 

लोड - http अनुरोध प्राप्त करें। अवधि - 300s, 1s - वार्मअप, लोड के 5 पुनरावृत्ति।



सेवा प्रतिक्रिया समय के प्रतिशत पर परिणाम।


हम देखते हैं कि इतने सरल परीक्षण पर Aiohttp ने 1000 RPS में एक अच्छा काम किया। सभी अब तक uvloop के बिना।

टॉरनेडो की तुलना पुराने (पैदावार) और नए (async) स्कूलों के कोरआउट्स से करें। लेखक जोर से async का उपयोग करने की सलाह देते हैं। हम यह सुनिश्चित कर सकते हैं कि वे वास्तव में बहुत तेज हैं।

1200 आरपीएस में, टॉरनेडो, यहां तक ​​कि नए स्कूल के कोरआउट्स के साथ, पहले से ही देना शुरू कर रहा है, और पुराने स्कूल कोराउटीन के साथ टॉर्नेडो पूरी तरह से उड़ा दिया गया है। अगर हम 50 एमएस के लिए सोते हैं, और माइक्रोएसओवर 80 एमएस के लिए जिम्मेदार है - यह किसी भी गेट में नहीं जाता है।

1,500 आरपीएस में टॉरनेडो का नया स्कूल पूरी तरह से छोड़ दिया गया है, जबकि Aiohttp अभी भी 3,000 RPS की सीमा से दूर है। सबसे दिलचस्प अभी आना बाकी है।

पाइफ्लेम, एक काम कर रहे माइक्रोसॉर्फ़ की रूपरेखा

आइए देखें कि इस समय प्रोसेसर के साथ क्या हो रहा है।



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

हम कंटेनर में कुछ सेवा शुरू करते हैं और उस पर लड़ाकू भार फेंकना शुरू करते हैं। अक्सर यह बहुत तुच्छ कार्य नहीं है - केवल ऐसे लोड को बनाने के लिए जो लड़ाई में है, क्योंकि अक्सर ऐसा होता है कि आप लोड परीक्षण, लुक और सब कुछ ठीक काम करने पर सिंथेटिक परीक्षण चलाते हैं। आप उस पर कॉम्बैट लोड बढ़ाते हैं, और यहां माइक्रोसेर सर्विस शुरू हो जाती है।

ऑपरेशन के दौरान, यह प्रोफाइलर हमारे लिए कॉल स्टैक का स्नैपशॉट करता है। आप सेवा को बिल्कुल भी नहीं बदल सकते हैं, बस पास में ही पिफल्म चलाएं। यह एक निश्चित समय अवधि में एक बार स्टैक ट्रेस एकत्र करेगा, और फिर एक शांत दृश्य करता है। यह प्रोफाइलर बहुत कम ओवरहेड देता है, खासकर जब cProfile की तुलना में। Pyflame कई कार्यक्रमों का समर्थन करता है। हमने इस चीज़ को सीधे ठेस में लॉन्च किया, और प्रदर्शन में बहुत गिरावट नहीं आई।



यहां, एक्स अक्ष समय की मात्रा है, कॉल की संख्या, जब स्टैक फ्रेम सभी पायथन स्टैक फ्रेम की सूची में था। यह प्रोसेसर समय की अनुमानित राशि है जो हमने स्टैक के इस विशेष फ्रेम में खर्च की है।

जैसा कि आप देख सकते हैं, यहाँ aiohttp में ज्यादातर समय बेकार चला जाता है। ललित: यह वह है जो हम एक अतुल्यकालिक सेवा से चाहते हैं ताकि यह अधिकांश समय नेटवर्क कॉल से निपटे। इस मामले में स्टैक की गहराई लगभग 15 फ्रेम है।

टॉर्नेडो (दूसरी तस्वीर) में एक ही भार के साथ, निष्क्रिय पर बहुत कम समय व्यतीत होता है और इस मामले में स्टैक की गहराई लगभग 30 फ्रेम होती है।

यहाँ svg का लिंक दिया गया है , आप खुद को ट्विस्ट कर सकते हैं।

अधिक जटिल अतुल्यकालिक बेंचमार्क

 async def work(): #     await asyncio.sleep(SLEEP_TIME) class HardWorkHandler(tornado.web.RequestHandler): timeout_time = datetime.timedelta(seconds=SLEEP_TIME / 2) async def get(self): await work() #     await tornado.gen.multi([work(), work()]) #     try: await tornado.gen.with_timeout(self.timeout_time, work()) except tornado.util.TimeoutError: #     pass 

125 एमएस के रनटाइम की अपेक्षा करें।



Uvloop के साथ बवंडर बेहतर पकड़ रखता है। लेकिन Aiohttp uvloop कुछ ज्यादा ही मदद करता है। Aiohttp 2300-2400 RPS पर बुरी तरह से व्यवहार करना शुरू कर देता है, और uvloop के साथ यह लोड सीमा को काफी बढ़ा देता है। आयात की एक पंक्ति, और अब आपके पास बहुत अधिक उत्पादक सेवा है।

परिणाम

मैं संक्षेप में बताऊंगा कि आज मैं आपको क्या बताना चाहता हूं।

• सबसे पहले, मैंने एक निश्चित कृत्रिम बेंचमार्क लॉन्च किया, जहां लंबे समय तक कोरटाइन की एक सभ्य मात्रा थी। हमारे परीक्षण में, Aiohttp ने टोरनेडो की तुलना में 2.5 गुना बेहतर प्रदर्शन किया।
• दूसरा तथ्य। Uvloop बहुत अच्छी तरह से Aiohttp के प्रदर्शन (Tornado से बेहतर) को बेहतर बनाने में मदद करता है।
• मैंने आपको Pyflame के बारे में बताया, जिसके साथ हम अक्सर उत्पादन में सीधे आवेदन को प्रोफाइल करते हैं।
• और हमने पैदावार (प्रतिफल) से उपज के बारे में भी बात की।

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

• मुकाबला सेवाओं के लिए, सीपीयू की खपत 2 गुना से अधिक घट गई।
• हमने http अनुरोधों के लिए समय-समय पर सम्मान देना शुरू किया।
• लेटेंसी सेवाएं 2 से 5 बार गिर गईं।

यहाँ बेंचमार्क के लिए एक लिंक है । यदि रुचि है, तो आप इसे दोहरा सकते हैं। ध्यान देने के लिए आप सभी का धन्यवाद। प्रश्न पूछें, मैं उन्हें उत्तर देने का प्रयास करूंगा।