Python proxy provjere: zašto Future.cancel() ostavlja niti aktivnim
Shvatite zašto otkazivanje futures na čekanju ne zaustavlja aktivne mrežne provjere i ograničite proxy utrku bez tvrdnje da dokazuje zdravlje odredišta.
Jedan worker pronađe upotrebljiv proxy. Vratite njegovu adresu, pozovete cancel na ostalim futures i očekujete da će mrežna aktivnost prestati. Možda neće.
Future se može otkazati prije nego što njegov callable počne. Kada nit već izvršava zahtjev, otkazivanje njenog Future ne prekida tu socket operaciju. Workeru je potrebna vlastita ograničena mrežna operacija i put za čišćenje.
Životni vijek executor-a je također važan. Napuštanje konteksta ThreadPoolExecutor čeka da njegov rad završi. Pronalaženje jednog brzog rezultata i potom čekanje na nekoliko sporih workera može učiniti ukupno kašnjenje pozivaoca potpuno drugačijim od prijavljene latencije pobjednika.
Ograničite utrku prije nego što počne
- Ograničite broj istovremenih provjera umjesto podnošenja neograničene javne liste. Besplatna lista proxyja daje kandidate za ulaz provjerivača, a protokol svake krajnje točke zadržava se za workera.
- Dajte svakom zahtjevu odgovarajuću politiku povezivanja i čitanja.
- Dajte pozivaocu ukupni budžet za odluku.
- Definirajte ko ispušta ili zatvara rezultate workera koji nadžive odluku.
Manje čekanja na Future nije isto što i skraćivanje njegovog osnovnog zahtjeva. Isto tako, napuštanje rezultata ne oslobađa odmah sve mrežne resurse.
Prvi uspješni rezultat je također samo prva uspješna provjera. Može zavisiti od raspoređivanja, keširanih veza i konkretnog odredišta provjere. Ne dokazuje da je krajnja točka univerzalno najbrža ni da će stvarni zadatak uspjeti.
Često je mali zadržani bazen sa nedavnim opažanjima jednostavniji od utrke s cijelom listom prije svakog preuzimanja. Koristite rezultat stvarne operacije za ažuriranje zapisa, uz kontroliranu politiku oporavka za neuspjehe. Preflight bi trebao zaraditi svoj trošak umjesto da udvostručuje svaki zadatak iz navike.