بررسی‌های پروکسی پایتون: چرا Future.cancel() رشته‌ها را در حال اجرا رها می‌کند

یک worker یک پروکسی قابل استفاده پیدا می‌کند. آدرس آن را برمی‌گردانید، روی futureهای دیگر cancel فراخوانی می‌کنید و انتظار دارید فعالیت شبکه متوقف شود. ممکن است متوقف نشود.

یک Future می‌تواند پیش از شروع callable آن لغو شود. وقتی یک رشته از قبل درخواستی را اجرا می‌کند، لغو Future آن عملیات سوکت را قطع نمی‌کند. worker به عملیات شبکه محدود خودش و مسیر پاک‌سازی نیاز دارد.

عمر executor نیز مهم است. ترک یک زمینه ThreadPoolExecutor منتظر تمام شدن کار آن می‌ماند. یافتن یک نتیجه سریع و سپس انتظار برای چندین worker کند می‌تواند تأخیر کل فراخواننده را کاملاً متفاوت از تأخیر گزارش‌شده برنده نشان دهد.

مسابقه را پیش از شروع محدود کنید

• به‌جای ارسال یک فهرست عمومی نامحدود، تعداد بررسی‌های همزمان را محدود کنید. فهرست رایگان پروکسی نامزدهایی برای ورودی بررسی‌کننده فراهم می‌کند و پروتکل هر نقطه پایانی برای worker نگه داشته می‌شود.
• به هر درخواست سیاست اتصال و خواندن مناسب بدهید.
• به فراخواننده بودجه تصمیم کلی بدهید.
• تعیین کنید چه کسی نتایج workerهایی را که از تصمیم جان سالم به در می‌برند تخلیه یا می‌بندد.

کمتر منتظر ماندن برای یک Future با کوتاه‌تر کردن درخواست زیربنایی آن یکی نیست. به همین ترتیب، رها کردن نتیجه همه منابع شبکه را فوراً آزاد نمی‌کند.

اولین نتیجه موفق نیز فقط اولین بررسی موفق است. می‌تواند به زمان‌بندی، اتصال‌های ذخیره‌شده و مقصد خاص بررسی بستگی داشته باشد. این ثابت نمی‌کند که نقطه پایانی جهانی سریع‌ترین است یا اینکه وظیفه واقعی موفق خواهد شد.

اغلب یک استخر کوچک نگه‌داشته‌شده با مشاهدات اخیر ساده‌تر از مسابقه دادن با کل فهرست پیش از هر دانلود است. از نتیجه عملیات واقعی برای به‌روزرسانی رکورد استفاده کنید، با سیاست بازیابی کنترل‌شده برای شکست‌ها. پیش‌بررسی باید هزینه‌اش را به دست آورد نه اینکه هر وظیفه را از روی عادت دو برابر کند.