Python प्रॉक्सी जाँच: Future.cancel() थ्रेड्स को क्यों चलता छोड़ देता है
समझें कि लंबित futures रद्द करना सक्रिय नेटवर्क जाँच को क्यों नहीं रोकता, और प्रॉक्सी रेस को सीमित करें बिना यह दावा किए कि यह गंतव्य के स्वास्थ्य को साबित करता है।
एक worker एक उपयोगी प्रॉक्सी ढूंढता है। आप उसका पता लौटाते हैं, बाकी futures पर cancel कॉल करते हैं, और उम्मीद करते हैं कि नेटवर्क गतिविधि रुक जाएगी। ऐसा हो सकता है कि न रुके।
किसी Future को उसके callable के शुरू होने से पहले रद्द किया जा सकता है। जब कोई थ्रेड पहले से अनुरोध निष्पादित कर रहा हो, तो उसके Future को रद्द करना उस सॉकेट ऑपरेशन को बाधित नहीं करता। worker को अपना सीमित नेटवर्क ऑपरेशन और सफ़ाई पथ चाहिए।
executor का जीवनकाल भी मायने रखता है। ThreadPoolExecutor संदर्भ छोड़ना उसके काम के पूरा होने की प्रतीक्षा करता है। एक तेज़ परिणाम ढूंढकर फिर कई धीमे workers की प्रतीक्षा करना कॉलर की कुल देरी को विजेता की बताई गई लेटेंसी जैसा बिल्कुल नहीं दिखा सकता।
रेस शुरू करने से पहले सीमित करें
- असीमित सार्वजनिक सूची जमा करने के बजाय एक साथ होने वाली जाँचों की संख्या सीमित करें। मुफ़्त प्रॉक्सी सूची जाँचकर्ता के इनपुट के लिए उम्मीदवार देती है, और हर एंडपॉइंट का प्रोटोकॉल worker के लिए रखा जाता है।
- हर अनुरोध को उपयुक्त कनेक्शन और पढ़ने की नीति दें।
- कॉलर को समग्र निर्णय बजट दें।
- तय करें कि निर्णय से आगे जीवित रहने वाले workers के परिणाम कौन खाली करता या बंद करता है।
किसी Future के लिए कम प्रतीक्षा करना उसके अंतर्निहित अनुरोध को छोटा करने के समान नहीं है। इसी तरह, परिणाम छोड़ देना हर नेटवर्क संसाधन को तुरंत मुक्त नहीं करता।
पहला सफल परिणाम भी केवल पहली सफल जाँच है। यह शेड्यूलिंग, कैश किए गए कनेक्शन और विशिष्ट जाँच गंतव्य पर निर्भर हो सकता है। यह सिद्ध नहीं करता कि एंडपॉइंट सार्वभौमिक रूप से सबसे तेज़ है या वास्तविक कार्य सफल होगा।
अक्सर हाल के अवलोकनों वाला एक छोटा रखा गया पूल हर डाउनलोड से पहले पूरी सूची के साथ रेस करने से सरल होता है। रिकॉर्ड अपडेट करने के लिए वास्तविक ऑपरेशन के परिणाम का उपयोग करें, विफलताओं के लिए नियंत्रित रिकवरी नीति के साथ। प्रीफ़्लाइट को अपनी लागत कमानी चाहिए, न कि आदत से हर कार्य को दोगुना करना।