क्या एसिंक फ़ंक्शन के लिए कोई लाभ है?

Question

Azure फ़ंक्शंस मुझे सी #/एफ # (और अधिक) फ़ंक्शन लिखने की अनुमति देता है जो कुछ शर्तों को निष्पादित किया जाता है। ये फ़ंक्शन एसिंक (कार्य को लौटकर) हो सकते हैं।

एज़ूर फ़ंक्शंस के बारे में अच्छी बात यह है कि वे लोड के आधार पर स्वचालित रूप से स्केल करते हैं। "क्लासिक" सर्वर पर एसिंक/प्रतीक्षा पैटर्न के बारे में अच्छी चीजों में से एक यह है कि आप कोर का बेहतर उपयोग कर सकते हैं ताकि आप अधिक अनुरोधों को संभाल सकें।

चूंकि एज़ूर फ़ंक्शन स्वचालित रूप से स्केल करता है, क्या मेरे लिए async फ़ंक्शन लिखने के लिए कोई लाभ हैं?

Answer 1

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

यदि आपका फ़ंक्शन ऐप क्लासिक SKU पर चल रहा है, तो आप हमेशा एक उदाहरण के लिए भुगतान कर रहे हैं, इसलिए यह स्पष्ट है कि आप संसाधनों को यथासंभव कुशलतापूर्वक उपयोग करना चाहते हैं।

गतिशील SKU में चलते समय, मुझे लगता है कि आपका प्रश्न यह था कि यदि हम केवल आपके कार्यों को आवश्यकतानुसार स्केल करेंगे, तो कौन परवाह करता है कि वे संसाधनों का कुशलतापूर्वक उपयोग कर रहे हैं? मैं अभी भी कहूंगा कि आपके कार्यों को कोड करना सबसे अच्छा है ताकि वे यथासंभव कुशलता से चल सकें। इस तरह हम वास्तव में आवश्यकता होने पर केवल आपको स्केल कर रहे हैं, और नए उदाहरणों के लिए किसी भी ठंडे प्रारंभ समय को कम करते हुए हम उन्हें स्पिन करते हैं।

Answer 2

जब भी आप गतिशील योजना पर Azure कार्यों के साथ async का उपयोग करते हैं तब भी आपको लाभ होता है। ऐसा इसलिए है क्योंकि आपका ऐप कम संसाधनों (विशेष रूप से धागे) का उपभोग कर रहा है, जिससे इसे अधिक कुशल और इसलिए कम महंगा बना दिया जाता है। कुछ उदाहरण दिमाग में आते हैं:

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

एक बार मौजूदा (व्यस्त) धागे की संख्या धागे की "न्यूनतम" संख्या, ThreadPool जिस दर पर है थ्रोटल होगा हिट करने के लिए नए सूत्र injects 500 मिलीसेकंड प्रति एक धागा। इसका मतलब यह है कि यदि आपके सिस्टम को आईओसीपी थ्रेड की आवश्यकता वाले काम का फट जाता है, तो वह उस काम को बहुत जल्दी संसाधित करेगा। हालांकि, अगर काम का विस्फोट कॉन्फ़िगर किया गया "न्यूनतम" सेटिंग से अधिक है, तो कुछ कामों को संसाधित करने में कुछ देरी होगी क्योंकि थ्रेडपूल दो चीजों में से एक के लिए इंतजार कर रहा है 1. एक मौजूदा धागा काम को संसाधित करने के लिए स्वतंत्र हो जाता है 2. कोई मौजूदा धागा 500ms के लिए मुक्त नहीं हो जाता है, इसलिए एक नया धागा बनाया जाता है।

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

यदि यह बहुत काम नहीं है, तो मैं अत्यधिक आपके कार्यों में एसिंक पैटर्न का लाभ लेने की सलाह देता हूं। उपरोक्त वर्णित कारणों से परे, प्लेटफॉर्म की क्षमता या गतिशील पैमाने तर्क की दक्षता के बारे में बहुत अधिक धारणा नहीं करना सर्वोत्तम है क्योंकि गलत धारणाएं आपको अधिक पैसे खर्च कर सकती हैं। :)