Проверки на Python прокси: защо Future.cancel() оставя нишките да работят

Един worker намира използваем прокси. Връщате адреса му, извиквате cancel на останалите futures и очаквате мрежовата активност да спре. Може и да не спре.

Един Future може да бъде отменен, преди извикваното му да стартира. След като нишка вече изпълнява заявка, отмяната на нейния Future не прекъсва тази socket операция. Worker-ът се нуждае от собствена ограничена мрежова операция и път за почистване.

Животът на executor-а също има значение. Напускането на контекст на ThreadPoolExecutor чака работата му да приключи. Намирането на един бърз резултат и след това чакането на няколко бавни worker-а може да направи общото закъснение на извикващия съвсем различно от отчетената латентност на победителя.

Ограничете състезанието, преди да го започнете

• Ограничете броя на едновременните проверки, вместо да подавате неограничен публичен списък. Безплатният списък с прокси предоставя кандидати за входа на проверяващия, като протоколът на всяка крайна точка се запазва за worker-а.
• Дайте на всяка заявка подходяща политика за свързване и четене.
• Дайте на извикващия общ бюджет за решение.
• Определете кой изчерпва или затваря резултатите от worker-и, които надживяват решението.

По-малкото чакане за Future не е същото като скъсяване на основната му заявка. По същия начин изоставянето на резултата не освобождава веднага всеки мрежов ресурс.

Първият успешен резултат е само първата успешна проверка. Той може да зависи от планирането, кешираните връзки и конкретната дестинация на проверката. Той не доказва, че крайната точка е универсално най-бързата или че реалната задача ще успее.

Често малък запазен пул с последни наблюдения е по-прост от състезание с целия списък преди всяко изтегляне. Използвайте резултата от реалната операция, за да обновите записа, с контролирана политика за възстановяване при откази. Предварителната проверка трябва да си изкарва разходите, вместо по навик да удвоява всяка задача.