ब्लकिङ प्रोक्सी-पूल लुकअपले Scrapy लाई रोक्न सक्छ

क्रलरमा पर्याप्त समवर्ती अनुरोधहरू कन्फिगर गरिएका छन्। तैपनि जब त्यसले प्रोक्सी पूलसँग अर्को ठेगाना माग्छ, त्यो रोकिन्छ। थप प्रोक्सी थप्दा त्यो रोकावटमा केही परिवर्तन हुँदैन।

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

काममा दुई अनुरोध छन्

एउटा अनुरोधले पूल सेवाबाट इन्डपोइन्ट प्राप्त गर्छ। अर्कोले त्यो इन्डपोइन्ट प्रयोग गरेर गन्तव्यसँग सम्पर्क गर्छ। दुवैलाई छुट्टाछुट्टै नाप्नुहोस् र रिपोर्ट गर्नुहोस्। ढिलो पूल API ले एप्लिकेसन जोडिनु अघि नै हरेक छानिएको प्रोक्सीलाई ढिलो देखाउन सक्छ।

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

हरेक अनुरोधका लागि स्वचालित रूपमा अर्को खोजी कल नगर्नुहोस्। छोटो अवधिको क्यास वा भाडामा लिइएको ब्याचले सेवाको वास्तविक इन्डपोइन्ट नीतिसँग मिल्ने हो भने पूल सेवामाथिको निर्भरता घटाउन सक्छ।

असफल लुकअपको अर्थ परिभाषित गर्नुहोस्

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

पूल API को आफ्नै मार्ग पनि खुला राख्नुहोस्। यदि यो आन्तरिक सेवा हो भने, यसको निजी होस्टनाम यसलाई छान्न मद्दत गर्ने त्यही प्रोक्सीमार्फत पठाउँदा चक्रीय निर्भरता सिर्जना हुन सक्छ।

खोजीले असम्बन्धित काम नरोकी काम गरेपछि सामान्य प्रोक्सी कारोबार जाँच्नुहोस्। ती छुट्टै मर्मत हुन्, र तिनको समयले लगमा छुट्टै फिल्ड पाउनुपर्छ।