Blokirajoče iskanje v proxy bazenu lahko ustavi Scrapy

Pajek ima nastavljenih dovolj sočasnih zahtev. Vseeno se ustavi vsakič, ko od proxy bazena zahteva drug naslov. Dodajanje več proxyjev tega postanka ne spremeni.

Pogost vzorec middleware kliče requests.get(pool_url) znotraj process_request(). To je sinhrona omrežna operacija na poti, ki naj bi sodelovala z asinhronim motorjem Scrapy. Medtem ko klic čaka, lahko zadržuje nepovezano delo v isti niti zanke dogodkov.

V opravilu sta dve zahtevi

Ena zahteva pridobi končno točko pri storitvi bazena. Druga uporabi to končno točko za stik s ciljem. Merite ju in poročajte ločeno. Počasen API bazena lahko naredi vsak izbrani proxy počasen, še preden se je aplikacija sploh povezala z njim.

Uporabite integracijo asinhronega odkrivanja, ki jo podpira nameščena različica Scrapy, ali pridobite in osvežujte omejen lokalni nabor končnih točk zunaj kritične poti vsake zahteve. Če je treba blokirajoče delo prestaviti, dajte temu izvajalcu lastne omejitve in obravnavo časovnih omejitev; neomejena čakalna vrsta samo premakne zamudo.

Ne pošiljajte samodejno še enega klica odkrivanja za vsako zahtevo. Kratkotrajni predpomnilnik ali najeta serija lahko zmanjšata odvisnost od storitve bazena, če se njuna življenjska doba ujema z dejansko politiko končnih točk storitve.

Določite, kaj pomeni neuspešno iskanje

Prazen ali neuspešen odgovor bazena ne sme tiho odstraniti metapodatkov proxyja in dovoliti neposredne zahteve. Izberite izrecen izid: čakanje v proračunu opravila, neuspeh ali uporaba odobrene predpomnjene končne točke.

Ohranjajte prosto tudi lastno pot API bazena. Če je to notranja storitev, lahko pošiljanje njenega zasebnega imena gostitelja skozi prav tisti proxy, ki pomaga pri izbiri, ustvari krožno odvisnost.

Ko odkrivanje deluje brez blokiranja nepovezanega dela, preglejte običajno transakcijo prek proxyja. To so ločena popravila in njihovo merjenje si zasluži ločena polja v dnevniku.