Un worker găsește un proxy utilizabil. Returnați adresa acestuia, apelați cancel pe celelalte future-uri și vă așteptați ca activitatea de rețea să se oprească. S-ar putea să nu se oprească.

Un Future poate fi anulat înainte ca callable-ul său să înceapă. Odată ce un fir execută deja o cerere, anularea Future-ului său nu întrerupe acea operațiune socket. Worker-ul are nevoie de propria operațiune de rețea limitată și de o cale de curățare.

Durata de viață a executor-ului contează și ea. Părăsirea unui context ThreadPoolExecutor așteaptă terminarea lucrului său. Găsirea unui rezultat rapid și apoi așteptarea mai multor worker-i lenți poate face întârzierea totală a apelantului să nu semene deloc cu latența raportată de câștigător.

Limitați cursa înainte de a o începe

  • Limitați numărul de verificări simultane în loc să trimiteți o listă publică nelimitată. Lista gratuită de proxy-uri oferă candidați pentru intrarea verificatorului, protocolul fiecărui endpoint fiind păstrat pentru worker.
  • Dați fiecărei cereri o politică adecvată de conectare și citire.
  • Dați apelantului un buget global de decizie.
  • Definiți cine golește sau închide rezultatele worker-ilor care supraviețuiesc deciziei.

A aștepta mai puțin un Future nu este același lucru cu a scurta cererea sa subiacentă. De asemenea, abandonarea rezultatului nu eliberează imediat toate resursele de rețea.

Primul rezultat reușit este și doar prima verificare reușită. Poate depinde de planificare, de conexiunile din cache și de destinația concretă a verificării. Nu stabilește că endpoint-ul este universal cel mai rapid sau că sarcina reală va reuși.

Adesea un pool mic păstrat cu observații recente este mai simplu decât să concurezi cu întreaga listă înainte de fiecare descărcare. Folosiți rezultatul operațiunii reale pentru a actualiza înregistrarea, cu o politică de recuperare controlată pentru eșecuri. Verificarea prealabilă ar trebui să își merite costul în loc să dubleze fiecare sarcină din obișnuință.

Articole similare