Python-proxytoetse: Waarom Future.cancel() drade laat aanhou loop

Een werker vind 'n bruikbare proxy. Jy gee sy adres terug, roep cancel op die ander futures, en verwag dat die netwerkaktiwiteit sal stop. Dit stop dalk nie.

'n Future kan gekanselleer word voordat sy callable begin. Sodra 'n draad reeds 'n versoek uitvoer, onderbreek die kansellasie van sy Future nie daardie socket-bewerking nie. Die werker het sy eie begrensde netwerkbewerking en opruimingspad nodig.

Die uitvoerder se leeftyd maak ook saak. Om 'n ThreadPoolExecutor-konteks te verlaat, wag tot sy werk klaar is. Een vinnige resultaat kry en dan op verskeie stadige werkers wag, kan die oproeper se totale vertraging heeltemal anders laat lyk as die wenner se gerapporteerde latency.

Begrens die wedloop voordat dit begin

• Beperk die aantal gelyktydige toetse in plaas daarvan om 'n onbeperkte openbare lys in te dien. Die gratis proxylis verskaf kandidate vir die toetser se invoer, terwyl elke eindpunt se protokol vir die werker behou word.
• Gee elke versoek 'n gepaste verbindings- en leesbeleid.
• Gee die oproeper 'n algehele besluitbegroting.
• Bepaal wie resultate van werkers wat die besluit oorleef, dreineer of sluit.

Om korter op 'n Future te wag is nie dieselfde as om sy onderliggende versoek korter te maak nie. Net so stel die laat vaar van die resultaat nie dadelik elke netwerkbron vry nie.

Die eerste suksesvolle resultaat is ook net die eerste suksesvolle toets. Dit kan afhang van skedulering, gekasde verbindings en die spesifieke toetsbestemming. Dit bewys nie dat die eindpunt universeel die vinnigste is of dat die werklike taak sal slaag nie.

Dikwels is 'n klein behoue poel met onlangse waarnemings eenvoudiger as om die hele lys voor elke aflaai te race. Gebruik die werklike bewerking se resultaat om die rekord by te werk, met 'n beheerde herstelbeleid vir foute. Die voorafvlug moet sy koste verdien eerder as om elke taak uit gewoonte te verdubbel.