Preverjanja proxyja v Pythonu: zakaj Future.cancel() pusti niti delujoče
Razumite, zakaj preklic čakajočih futures ne ustavi aktivnih omrežnih preverjanj, in omejite dirko proxyja, ne da bi trdili, da dokazuje zdravje cilja.
En worker najde uporaben proxy. Vrnete njegov naslov, pokličete cancel na drugih futures in pričakujete, da se bo omrežna dejavnost ustavila. Morda se ne bo.
Future je mogoče preklicati, preden se njegov callable začne. Ko nit že izvaja zahtevo, preklic njenega Future ne prekine te socketne operacije. Worker potrebuje svojo omejeno omrežno operacijo in pot čiščenja.
Tudi življenjska doba izvajalca je pomembna. Zapustitev konteksta ThreadPoolExecutor čaka, da se njegovo delo konča. Iskanje enega hitrega rezultata in nato čakanje na več počasnih workerjev lahko povzroči, da celotna zakasnitev klicatelja sploh ni podobna latenci, ki jo je poročal zmagovalec.
Omejite dirko, preden se začne
- Omejite število hkratnih preverjanj, namesto da pošljete neomejen javni seznam. Brezplačni seznam proxyjev ponuja kandidate za vhod preverjevalca, pri čemer se protokol vsake končne točke ohrani za workera.
- Vsaki zahtevi dajte ustrezno politiko povezovanja in branja.
- Klicatelju dajte skupni proračun za odločitev.
- Določite, kdo izprazni ali zapre rezultate workerjev, ki preživijo odločitev.
Krajše čakanje na Future ni isto kot skrajšanje njegove osnovne zahteve. Prav tako opustitev rezultata ne sprosti takoj vseh omrežnih virov.
Prvi uspešni rezultat je tudi le prvo uspešno preverjanje. Lahko je odvisno od razporejanja, predpomnjenih povezav in konkretnega cilja preverjanja. Ne dokazuje, da je končna točka univerzalno najhitrejša ali da bo resnična naloga uspela.
Pogosto je majhen zadržan nabor z nedavnimi opažanji preprostejši od tekmovanja s celotnim seznamom pred vsakim prenosom. Uporabite rezultat resnične operacije za posodobitev zapisa, skupaj s nadzorovano politiko obnovitve ob napakah. Predhodno preverjanje bi moralo zaslužiti svoje stroške, namesto da bi iz navade podvojilo vsako nalogo.