Python-välityspalvelintarkistukset: miksi Future.cancel() jättää säikeet käyntiin
Ymmärrä, miksi odottavien futurejen peruuttaminen ei pysäytä aktiivisia verkkotarkistuksia, ja rajaa välityspalvelinkilpailu väittämättä, että se todistaisi kohteen terveyden.
Yksi worker löytää käyttökelpoisen välityspalvelimen. Palautat sen osoitteen, kutsut cancelia muille futureille ja odotat verkkotoiminnan pysähtyvän. Se ei välttämättä pysähdy.
Future voidaan peruuttaa ennen kuin sen callable alkaa. Kun säie jo suorittaa pyyntöä, sen Futuren peruuttaminen ei keskeytä sitä socket-toimintoa. Worker tarvitsee oman rajatun verkkotoimintonsa ja siivouspolkunsa.
Myös suorittajan elinkaari on tärkeä. ThreadPoolExecutor-kontekstista poistuminen odottaa sen työn valmistumista. Yhden nopean tuloksen löytäminen ja sitten useiden hitaiden workerien odottaminen voi saada kutsujan kokonaisviiveen näyttämään täysin erilaiselta kuin voittajan ilmoittama latenssi.
Rajaa kilpailu ennen sen aloittamista
- Rajoita samanaikaisten tarkistusten määrää sen sijaan, että lähettäisit rajoittamattoman julkisen listan. Ilmainen välityspalvelinlista tarjoaa ehdokkaita tarkistajan syötteeksi, ja jokaisen päätepisteen protokolla säilytetään workerille.
- Anna jokaiselle pyynnölle sopiva yhteys- ja lukukäytäntö.
- Anna kutsujalle kokonaispäätösbudjetti.
- Määritä, kuka tyhjentää tai sulkee päätöksen yli elävien workerien tulokset.
Futuren vähemmän odottaminen ei ole sama kuin sen taustalla olevan pyynnön lyhentäminen. Samoin tuloksesta luopuminen ei vapauta kaikkia verkkoresursseja välittömästi.
Ensimmäinen onnistunut tulos on myös vain ensimmäinen onnistunut tarkistus. Se voi riippua ajoituksesta, välimuistiin tallennetuista yhteyksistä ja tietystä tarkistuskohteesta. Se ei osoita, että päätepiste on kaikkialla nopein tai että varsinainen tehtävä onnistuu.
Usein pieni säilytetty pooli tuoreilla havainnoilla on yksinkertaisempi kuin kilpajuoksu koko listan kanssa ennen jokaista latausta. Käytä todellisen toiminnon tulosta tietueen päivittämiseen, yhdessä hallitun palautumiskäytännön kanssa epäonnistumisiin. Esitarkistuksen pitäisi ansaita kustannuksensa sen sijaan, että se kaksinkertaistaisi jokaisen tehtävän tottumuksesta.