Перевірки проксі на Python: чому Future.cancel() залишає потоки працювати

Один worker знаходить придатний проксі. Ви повертаєте його адресу, викликаєте cancel для інших futures і очікуєте, що мережева активність припиниться. Може й не припинитися.

Future можна скасувати до запуску його callable. Якщо потік уже виконує запит, скасування його Future не перериває цю операцію з сокетом. Worker потребує власної обмеженої мережевої операції та шляху очищення.

Час життя executor також важливий. Вихід із контексту ThreadPoolExecutor чекає завершення його роботи. Знайти один швидкий результат, а потім чекати кількох повільних worker — через це загальна затримка того, хто викликає, може зовсім не скидатися на заявлену затримку переможця.

Обмежте гонку до її початку

• Обмежте кількість одночасних перевірок замість подання необмеженого публічного списку. Безкоштовний список проксі надає кандидатів для входу перевіряльника, причому протокол кожного кінцевого пункту зберігається для worker.
• Дайте кожному запиту відповідну політику з'єднання та читання.
• Дайте тому, хто викликає, загальний бюджет рішення.
• Визначте, хто спорожнює або закриває результати worker, які переживають рішення.

Менше чекати Future — не те саме, що скоротити його базовий запит. Так само відмова від результату не звільняє одразу всі мережеві ресурси.

Перший успішний результат — це також лише перша успішна перевірка. Він може залежати від планування, кешованих з'єднань і конкретного призначення перевірки. Він не доводить, що кінцевий пункт є універсально найшвидшим або що реальне завдання вдасться.

Часто невеликий збережений пул зі свіжими спостереженнями простіший, ніж гонка з усім списком перед кожним завантаженням. Використовуйте результат реальної операції для оновлення запису разом із контрольованою політикою відновлення після збоїв. Попередня перевірка має окупати свою вартість, а не подвоювати кожне завдання за звичкою.