ब्लॉकिंग प्रॉक्सी-पूल लुकअप Scrapy को रोक सकता है

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

एक सामान्य मिडलवेयर पैटर्न requests.get(pool_url) को process_request() के अंदर कॉल करता है। यह उस पथ पर एक सिंक्रोनस नेटवर्क ऑपरेशन है जिसे Scrapy के असिंक्रोनस इंजन के साथ सहयोग करना चाहिए। जब कॉल प्रतीक्षा कर रहा होता है, तो वह उसी इवेंट-लूप थ्रेड पर असंबंधित काम को रोक सकता है।

कार्य में दो अनुरोध हैं

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

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

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

तय करें कि विफल लुकअप का क्या अर्थ है

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

पूल API का अपना मार्ग भी खुला रखें। यदि यह आंतरिक सेवा है, तो उसका निजी होस्टनाम उसी प्रॉक्सी के माध्यम से भेजना जिसे चुनने में वह मदद करती है, चक्रीय निर्भरता पैदा कर सकता है।

डिस्कवरी के असंबंधित काम को रोके बिना काम करने के बाद, सामान्य प्रॉक्सी लेनदेन की जाँच करें। ये अलग मरम्मतें हैं, और उनका समय लॉग में अलग फ़ील्ड का हक़दार है।