asyncio क्या है?

Scrapeless Scraping Browser क्लाउड ब्राउज़र कार्यान्वयन प्रदान करता है जिसे पायथन आवेदन असंक्रमणीय वेब संग्रह कार्यप्रवाह में समन्वित कर सकते हैं।

asyncio पायथन का मानक पुस्तकालय है जो async और await के साथ समवर्ती कोड लिखने के लिए है। यह coroutine, कार्य, और असंक्रमण I/O को एक इवेंट लूप के माध्यम से समन्वित करता है। एक स्क्रैपिंग आवेदन में, asyncio स्वतंत्र नेटवर्क प्रतीक्षा को ओवरलैप कर सकता है जबकि कार्यक्रम प्रत्येक ऑपरेशन के पूर्ण होने पर नज़र रखता है।

asyncio एक HTTP क्लाइंट या एक HTML पार्सर नहीं है। आप दस्तावेज़ों का अनुरोध करने के लिए एक असंक्रमणीय नेटवर्किंग पुस्तकालय का उपयोग करते हैं और उनके सामग्री को निकालने के लिए एक पार्सर का उपयोग करते हैं। asyncio उन ऑपरेशनों के बीच समन्वय प्रदान करता है। उस सीमा को समझना इसका उपयोगिता और सामान्य कारणों को समझाने में मदद करता है कि एक स्पष्ट असंक्रमणीय कार्यक्रम फिर भी अनुक्रम में क्यों चल रहा है।

asyncio क्या समस्या हल करता है?

asyncio एक कार्यक्रम को अन्य कार्य पर प्रगति करने में मदद करता है जबकि एक ऑपरेशन संगत I/O की प्रतीक्षा करता है। एक पृष्ठ अनुरोध एक कनेक्शन या प्रतिक्रिया बाइट्स की प्रतीक्षा करने में समय बिता सकता है। यदि आवेदन को दूसरी स्वतंत्र अनुरोध शुरू करने से पहले उस प्रतिक्रिया की आवश्यकता नहीं है, तो वे प्रतीक्षा अवधि ओवरलैप हो सकती हैं।

यह पायथन का असंक्रमण I/O मॉडल नेटवर्क संचालन, कार्य, उप-प्रक्रियाओं और समन्वय के लिए उच्च-स्तरीय सुविधाएँ प्रदान करता है। पुस्तकालय इन सुविधाओं पर निर्माण करते हैं ताकि वे इवेंट लूप के साथ सहयोग करने वाले संचालन को उजागर कर सकें। आवेदन को तय करने की ज़िम्मेदारी रहती है कि कौन सा कार्य स्वतंत्र है और कितना स्वीकार करना है।

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

Coroutine, कार्य, और इवेंट लूप

एक coroutine एक असंक्रमणीय कार्य का वर्णन करता है, एक कार्य एक coroutine को निष्पादन के लिए निर्धारित करता है, और इवेंट लूप तैयार कार्य को समन्वित करता है। एक coroutine फ़ंक्शन को कॉल करने पर एक coroutine ऑब्जेक्ट बनता है न कि स्वचालित रूप से इसके शरीर को पूरा करता है। कॉल करने वाले को इसकी प्रतीक्षा करनी चाहिए या इसे एक कार्य के रूप में चलाने की व्यवस्था करनी चाहिए।

यह पायथन का coroutine और कार्य जीवनचक्र स्पष्ट करता है कि शेड्यूलिंग, प्रतीक्षा, और पूर्णता कैसे इंटरैक्ट करते हैं। एक इवेंट-लूप थ्रेड के भीतर, एक कार्य तब तक चलता है जब तक कि यह स्थगित या समाप्त नहीं होता; अन्य तैयार कार्य फिर आगे बढ़ सकते हैं। यह सहकारी शेड्यूलिंग है, इसलिए कोड जो लूप को बिना yielding किए Occupies करता है, असंबंधित कार्यों को विलंबित कर सकता है।

Await का अर्थ है कि वर्तमान coroutine एक awaitable के परिणाम पर निर्भर करता है। यदि ऑपरेशन को प्रतीक्षा करनी है, तो नियंत्रण इवेंट लूप को वापस लौट सकता है। इसका अर्थ यह नहीं है कि “एक पृष्ठभूमि थ्रेड शुरू करें,” और यह यह सुनिश्चित नहीं करता है कि एक स्थगन हर बार होता है। एक पहले से पूर्ण ऑपरेशन तुरंत जारी रह सकता है।

एक सामान्य स्क्रिप्ट की सीमा पर, asyncio.run असंक्रमणीय प्रवेश बिंदु का प्रबंधन करता है। एक ऐसे मेज़बान के अंदर जो पहले से ही एक इवेंट लूप का मालिक है, जैसे कुछ इंटरएक्टिव वातावरण या सेवाएँ, उस मेज़बान के समर्थित असिंक्रोनिक एकीकरण का उपयोग करें बजाय एक नेस्टेड लूप शुरू करने की कोशिश करने के। लूप बनाने वाला घटक को अपने जीवनचक्र का भी स्वामी होना चाहिए।

समवर्तीता CPU समानांतरता से भिन्न है

asyncio ओवरलैपिंग ऑपरेशनों को समन्वित करता है; यह स्वचालित रूप से CPU-भारी पायथन कार्यों को कई कोर पर नहीं चलाता है। एक लंबी गणना या समन्वयित पार्सर कॉल फिर भी इवेंट-लूप थ्रेड को कवर कर सकता है। नेटवर्क भाग असंक्रमणीय हो सकते हैं जबकि स्थानीय प्रसंस्करण एक बोतल की गला बना रहता है।

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

निष्पादन मॉडल को बदलने से पहले मापें। यदि अनुरोध अपने समय का अधिकांश हिस्सा स्रोत पर प्रतीक्षा करने में बिताते हैं, तो ओवरलैपिंग प्रतीक्षा मदद कर सकती है। यदि प्रत्येक प्रतिक्रिया एक बड़े रूपांतरण को प्रेरित करता है जो लूप को कवर करता है, तो अधिक निर्धारित डाउनलोड केवल स्मृति दबाव बढ़ा सकते हैं। एक नियंत्रित प्रसंस्करण चरण के साथ एक छोटे सक्रिय सेट अधिक अनुमानित पूर्णता उत्पन्न कर सकता है।

क्यों एक लूप के साथ Await फिर भी अनुक्रम में हो सकता है

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

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

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

क्यूज़ और सेमाफोर विभिन्न संसाधनों को नियंत्रित करते हैं

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

यह asyncio कतार मॉडल उस समय उत्पादक को प्रतीक्षा करने का अवसर दे सकता है जब एक कॉन्फ़िगर की गई कतार भर जाती है। इससे बैकप्रेशर उत्पन्न होता है: उपभोक्ता जब नहीं पकड़ते हैं तो उत्पादन धीमा हो जाता है। इसलिए, एक श्रमिक आधारित संग्रहकर्ता अपनी सक्रिय ऑपरेशन और आरंभ करने के लिए प्रतीक्षा कर रहे कार्यों को सीमित कर सकता है।

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

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

रद्द करना और शटडाउन स्वामित्व की आवश्यकता है

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

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

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

एक उदाहरणात्मक असिंक्रोनस संग्रह पाइपलाइन

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

अधिग्रहण विधि समन्वय मॉडल को बदले बिना भिन्न हो सकती है। एक असिंक्रोनस HTTP क्लाइंट उन पृष्ठों के लिए उपयुक्त होता है जिनकी प्रतिक्रिया पहले से ही डेटा शामिल करती है। स्क्रैपलेस स्क्रैपिंग ब्राउज़र गतिशील पृष्ठों के लिए ब्राउज़र निष्पादन प्रदान करता है। प्रत्येक ऑपरेशन को अभी भी एक परिभाषित इनपुट, एक अपेक्षित परिणाम, और एक संसाधन दायरा की आवश्यकता होती है।

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

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

निष्कर्ष

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