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

Еден worker наоѓа употребливо прокси. Ја враќате неговата адреса, повикувате cancel на другите futures и очекувате мрежната активност да запре. Може и да не запре.

Future може да се откаже пред да започне неговиот callable. Откако нишка веќе извршува барање, откажувањето на нејзиниот Future не ја прекинува таа socket операција. Worker-от бара сопствена ограничена мрежна операција и пат за чистење.

Животниот век на executor-от исто така е важен. Напуштањето на контекстот на ThreadPoolExecutor чека неговата работа да заврши. Наоѓањето на еден брз резултат и потоа чекањето на неколку бавни worker-и може да го направи вкупното доцнење на повикувачот сосема различно од пријавената латентност на победникот.

Ограничете ја трката пред да започне

• Ограничете го бројот на истовремени проверки наместо да поднесувате неограничена јавна листа. Бесплатната листа со прокси обезбедува кандидати за влезот на проверувачот, при што протоколот на секоја крајна точка се чува за worker-от.
• Дајте ѝ на секое барање соодветна политика за поврзување и читање.
• Дајте му на повикувачот вкупен буџет за одлука.
• Дефинирајте кој ги испушта или затвора резултатите од worker-ите што ја надживуваат одлуката.

Помалку чекање за Future не е исто како скратување на неговото основно барање. Исто така, напуштањето на резултатот не го ослободува веднаш секој мрежен ресурс.

Првиот успешен резултат е исто така само првата успешна проверка. Тој може да зависи од распоредувањето, кешираните врски и конкретното одредиште на проверката. Тој не докажува дека крајната точка е универзално најбрза или дека вистинската задача ќе успее.

Често мал задржан базен со скорешни набљудувања е поедноставен од трка со целата листа пред секое преземање. Користете го резултатот од вистинската операција за да го ажурирате записот, со контролирана политика за закрепнување при неуспеси. Претходната проверка треба да ја заработи својата цена наместо од навика да ја удвојува секоја задача.