Python proxy provjere: zašto Future.cancel() ostavlja niti aktivnim
Shvatite zašto otkazivanje futuresa 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 futuresima 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. Kad nit već izvršava zahtjev, otkazivanje njezinog Futurea ne prekida tu socket operaciju. Workeru je potrebna vlastita ograničena mrežna operacija i put za čišćenje.
Životni vijek executor-a također je važan. Napuštanje konteksta ThreadPoolExecutor čeka da njegov rad završi. Pronalaženje jednog brzog rezultata i zatim čekanje na nekoliko sporih workera može učiniti ukupno kašnjenje pozivatelja posve drukčijim od prijavljene latencije pobjednika.
Ograničite utrku prije nego što počne
- Ograničite broj istovremenih provjera umjesto podnošenja neograničenog javnog popisa. Besplatni popis 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 pozivatelju ukupni proračun za odluku.
- Definirajte tko ispušta ili zatvara rezultate workera koji nadžive odluku.
Manje čekanja na Future nije isto što i skraćivanje njegova osnovnog zahtjeva. Isto tako, napuštanje rezultata ne oslobađa odmah sve mrežne resurse.
Prvi uspješni rezultat ujedno je samo prva uspješna provjera. Može ovisiti o raspoređivanju, predmemoriranim vezama i konkretnom odredištu provjere. Ne dokazuje da je krajnja točka univerzalno najbrža ni da će stvarni zadatak uspjeti.
Često je mali zadržani skup s nedavnim opažanjima jednostavniji od utrke s cijelim popisom prije svakog preuzimanja. Upotrijebite rezultat stvarne operacije za ažuriranje zapisa, uz kontroliranu politiku oporavka za neuspjehe. Prethodna provjera trebala bi zaraditi svoj trošak umjesto da udvostručuje svaki zadatak iz navike.