पायथन और तेजी से HTTP क्लाइंट

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



पायथन के लिए कई HTTP क्लाइंट हैं। उनमें से सबसे आम है, और, इसके अलावा, जो काम करना आसान है, उसे अनुरोध कहा जा सकता है। आज, यह ग्राहक वास्तविक मानक है।

स्थायी कनेक्शन

HTTP के साथ काम करने पर विचार करने वाला पहला अनुकूलन वेब सर्वर के लिए लगातार कनेक्शन का उपयोग करना है। HTTP 1.1 से लगातार कनेक्शन मानक बन गए हैं, लेकिन कई एप्लिकेशन अभी भी उनका उपयोग नहीं करते हैं। यह दोष स्पष्ट करना आसान है, यह जानते हुए कि requests पुस्तकालय का उपयोग करते requests सरल मोड में (उदाहरण के लिए, इसकी get विधि का उपयोग करके), सर्वर से कनेक्शन इसे प्रतिक्रिया प्राप्त करने के बाद बंद हो जाता है। इससे बचने के लिए, एप्लिकेशन को Session ऑब्जेक्ट का उपयोग करने की आवश्यकता होती है, जो खुले कनेक्शन का पुन: उपयोग करने की अनुमति देता है:

 import requests session = requests.Session() session.get("http://example.com") #    session.get("http://example.com") 

कनेक्शन पूल में जमा हो जाते हैं (यह डिफ़ॉल्ट रूप से 10 कनेक्शन के लिए डिफ़ॉल्ट है)। पूल आकार अनुकूलित किया जा सकता है:

 import requests session = requests.Session() adapter = requests.adapters.HTTPAdapter(    pool_connections=100,    pool_maxsize=100) session.mount('http://', adapter) response = session.get("http://example.org") 

कई HTTP अनुरोध भेजने के लिए टीसीपी कनेक्शन का पुन: उपयोग करने से एप्लिकेशन को कई प्रदर्शन लाभ मिलते हैं:

• प्रोसेसर पर लोड को कम करना और रैम की आवश्यकता को कम करना (इस तथ्य के कारण कि एक ही समय में कम कनेक्शन खुलते हैं)।
• एक के बाद एक आने वाले अनुरोधों को निष्पादित करते समय देरी को कम करना (कोई टीसीपी हैंडशेक प्रक्रिया नहीं है)।
• टीसीपी कनेक्शन को बंद करने के लिए अतिरिक्त समय के बिना अपवाद फेंके जा सकते हैं।

HTTP 1.1 अनुरोधों के पाइपलाइनिंग का भी समर्थन करता है। यह आपको पहले भेजे गए अनुरोधों के जवाब की प्रतीक्षा किए बिना एक ही कनेक्शन के भीतर कई अनुरोध भेजने की अनुमति देता है (अर्थात, "पैकेट" में अनुरोध भेजें)। दुर्भाग्य से, requests लाइब्रेरी इस सुविधा का समर्थन नहीं करती है। हालाँकि, समानांतर रूप से उन्हें संसाधित करने के लिए पाइपलाइनिंग अनुरोध उतने तेज़ नहीं हो सकते हैं। और, इसके अलावा, इस पर ध्यान देने के लिए उपयुक्त है: "पैकेट" अनुरोधों का जवाब सर्वर द्वारा उसी क्रम में भेजा जाना चाहिए, जिसमें उसे ये अनुरोध मिले थे। परिणाम FIFO सिद्धांत ("पहली बार, पहले बाहर" - "पहले आओ, पहले छोड़ो") के आधार पर सबसे कुशल अनुरोध प्रसंस्करण योजना नहीं है।

समानांतर क्वेरी प्रसंस्करण

requests में एक और गंभीर खामी भी है। यह एक सिंक्रोनस लाइब्रेरी है। requests.get("http://example.org") तरह एक विधि कॉल requests.get("http://example.org") एक पूर्ण HTTP सर्वर प्रतिक्रिया प्राप्त होने तक कार्यक्रम को अवरुद्ध करता है। तथ्य यह है कि आवेदन के लिए इंतजार करना पड़ता है और कुछ भी नहीं किया जाता है, सर्वर के साथ बातचीत के संगठन की इस योजना का ऋण नहीं माना जा सकता है। क्या केवल प्रतीक्षा के बजाय कार्यक्रम को कुछ उपयोगी बनाना संभव है?

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

 from concurrent import futures import requests with futures.ThreadPoolExecutor(max_workers=4) as executor:    futures = [        executor.submit(            lambda: requests.get("http://example.org"))        for _ in range(8)    ] results = [    f.result().status_code    for f in futures ] print("Results: %s" % results) 

यह बहुत उपयोगी पैटर्न अनुरोध-वायदा पुस्तकालय में लागू किया गया है। उसी समय, डेवलपर के लिए Session ऑब्जेक्ट का उपयोग पारदर्शी है:

 from requests_futures import sessions session = sessions.FuturesSession() futures = [    session.get("http://example.org")    for _ in range(8) ] results = [    f.result().status_code    for f in futures ] print("Results: %s" % results) 

डिफ़ॉल्ट रूप से, दो थ्रेड्स वाला एक कार्यकर्ता बनाया जाता है, लेकिन प्रोग्राम इस मूल्य को आसानी से FuturSession तर्क या यहां तक ​​कि FuturSession ऑब्जेक्ट के अपने स्वयं के निष्पादक को पारित करके सेट कर सकता है। उदाहरण के लिए, यह इस तरह दिख सकता है:

 FuturesSession(executor=ThreadPoolExecutor(max_workers=10)) 

अनुरोधों के साथ अतुल्यकालिक काम

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

पायथन 3.5 के साथ शुरू, मानक भाषा सुविधाओं में asyncio का उपयोग करके अतुल्यकालिक प्रोग्रामिंग शामिल है। Aiohttp लाइब्रेरी डेवलपर को एसिंक्रोनस पर आधारित एक एसिंक्रोनस HTTP क्लाइंट के साथ प्रदान करता है। यह लाइब्रेरी एप्लिकेशन को अनुरोधों की एक श्रृंखला भेजने और काम करना जारी रखने की अनुमति देती है। उसी समय, एक और अनुरोध भेजने के लिए, आपको पहले भेजे गए अनुरोध की प्रतिक्रिया की प्रतीक्षा करने की आवश्यकता नहीं है। HTTP अनुरोधों को पाइपलाइन करने के विपरीत, aiohttp कई कनेक्शनों का उपयोग करके समानांतर में अनुरोध भेजता है। यह ऊपर वर्णित "फीफो समस्या" से बचा जाता है। यहाँ है कि aiohttp का उपयोग aiohttp दिखता है:

 import aiohttp import asyncio async def get(url):    async with aiohttp.ClientSession() as session:        async with session.get(url) as response:            return response loop = asyncio.get_event_loop() coroutines = [get("http://example.com") for _ in range(8)] results = loop.run_until_complete(asyncio.gather(*coroutines)) print("Results: %s" % results) 

ऊपर वर्णित सभी दृष्टिकोण ( Session , स्ट्रीम, concurrent.futures asyncio या asyncio का उपयोग करके) HTTP क्लाइंट को गति देने के लिए अलग-अलग तरीके प्रदान करते हैं।

उत्पादकता

निम्न कोड एक उदाहरण है जिसमें HTTP क्लाइंट httpbin.org सर्वर को अनुरोध भेजता है। सर्वर एक एपीआई का समर्थन करता है जो अन्य चीजों के अलावा, एक प्रणाली का अनुकरण कर सकता है जो अनुरोध का जवाब देने में लंबा समय लेता है (इस मामले में, यह 1 सेकंड है)। यहाँ, उपरोक्त सभी तकनीकों को लागू किया गया है और उनके प्रदर्शन को मापा गया है:

 import contextlib import time import aiohttp import asyncio import requests from requests_futures import sessions URL = "http://httpbin.org/delay/1" TRIES = 10 @contextlib.contextmanager def report_time(test):    t0 = time.time()    yield    print("Time needed for `%s' called: %.2fs"          % (test, time.time() - t0)) with report_time("serialized"):    for i in range(TRIES):        requests.get(URL) session = requests.Session() with report_time("Session"):    for i in range(TRIES):        session.get(URL) session = sessions.FuturesSession(max_workers=2) with report_time("FuturesSession w/ 2 workers"):    futures = [session.get(URL)               for i in range(TRIES)]    for f in futures:        f.result() session = sessions.FuturesSession(max_workers=TRIES) with report_time("FuturesSession w/ max workers"):    futures = [session.get(URL)               for i in range(TRIES)]    for f in futures:        f.result() async def get(url):    async with aiohttp.ClientSession() as session:        async with session.get(url) as response:            await response.read() loop = asyncio.get_event_loop() with report_time("aiohttp"):    loop.run_until_complete(        asyncio.gather(*[get(URL)                         for i in range(TRIES)])) 

इस कार्यक्रम को शुरू करने के बाद प्राप्त परिणाम इस प्रकार हैं:

 Time needed for `serialized' called: 12.12s Time needed for `Session' called: 11.22s Time needed for `FuturesSession w/ 2 workers' called: 5.65s Time needed for `FuturesSession w/ max workers' called: 1.25s Time needed for `aiohttp' called: 1.19s 

यहां परिणामों का एक चार्ट दिया गया है।

HTTP अनुरोधों को निष्पादित करने के लिए विभिन्न तरीकों के प्रदर्शन के एक अध्ययन के परिणाम

यह आश्चर्य की बात नहीं है कि सबसे सरल तुल्यकालिक क्वेरी निष्पादन योजना सबसे धीमी निकली। यहाँ मुद्दा यह है कि यहाँ प्रश्नों को एक-एक करके निष्पादित किया जाता है, बिना कनेक्शन का उपयोग किए। नतीजतन, 10 प्रश्नों को पूरा करने में 12 सेकंड लगते हैं।

Session ऑब्जेक्ट का उपयोग करना, और, परिणामस्वरूप, कनेक्शन का पुन: उपयोग, 8% समय बचाता है। यह पहले से ही बहुत अच्छा है, और इसे प्राप्त करना बहुत सरल है। जो कोई भी प्रदर्शन के बारे में परवाह करता है, उसे कम से कम Session वस्तु का उपयोग करना चाहिए।

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

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

aiohttp एक विकल्प, विशेष रूप से अच्छा विकल्प नहीं है कि समानांतर में सैकड़ों धागे का प्रबंधन किया जा सके।

स्ट्रीम डाटा प्रोसेसिंग

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

यहां बताया गया है कि requests का उपयोग करते हुए डेटा प्रोसेसिंग स्ट्रीमिंग का संगठन कैसा दिखता है:

 import requests #  `with`          #     . with requests.get('http://example.org', stream=True) as r:    print(list(r.iter_content())) 

यहाँ कैसे aiohttp का उपयोग करके डेटा को स्ट्रीम किया aiohttp :

 import aiohttp import asyncio async def get(url):    async with aiohttp.ClientSession() as session:        async with session.get(url) as response:            return await response.content.read() loop = asyncio.get_event_loop() tasks = [asyncio.ensure_future(get("http://example.com"))] loop.run_until_complete(asyncio.wait(tasks)) print("Results: %s" % [task.result() for task in tasks]) 

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

परिणाम

मुझे उम्मीद है कि HTTP क्लाइंट के ऑपरेशन को ऑप्टिमाइज़ करने के विभिन्न तरीकों के बारे में मेरी बात आपको यह चुनने में मदद करेगी कि आपके पायथन एप्लिकेशन को सबसे अच्छा क्या सूट करता है।

प्रिय पाठकों! यदि आप अभी भी पायथन अनुप्रयोगों में HTTP अनुरोधों के साथ काम का अनुकूलन करने के लिए कोई अन्य तरीका जानते हैं, तो कृपया उन्हें साझा करें।