Et blokkerende proxy-pool-oppslag kan stoppe Scrapy

Kravleren har rikelig med samtidige forespørsler konfigurert. Likevel stopper den hver gang den ber proxy-poolen om en annen adresse. Å legge til flere proxyer endrer ikke den pausen.

Et vanlig middleware-mønster kaller requests.get(pool_url) inne i process_request(). Det er en synkron nettverksoperasjon på en sti som forventes å samarbeide med Scrapys asynkrone motor. Mens kallet venter, kan det holde tilbake urelatert arbeid på samme hendelsesløkke-tråd.

Det er to forespørsler i jobben

Én forespørsel henter et endpoint fra pooltjenesten. Den andre bruker det endpointet til å kontakte destinasjonen. Mål og rapporter dem hver for seg. En treg pool-API kan få hver valgt proxy til å virke treg før applikasjonen i det hele tatt har koblet til den.

Bruk en asynkron oppdagelsesintegrasjon som den installerte Scrapy-versjonen støtter, eller hent og oppdater et begrenset lokalt endpoint-sett utenfor den kritiske stien per forespørsel. Hvis blokkerende arbeid må flyttes, gi den utføreren egne grenser og tidsavbruddsbehandling; en ubegrenset kø flytter bare forsinkelsen.

Ikke send automatisk enda et oppdagelseskall for hver forespørsel. En kortvarig cache eller en leid batch kan redusere avhengigheten av pooltjenesten, forutsatt at levetiden passer til tjenestens faktiske endpoint-policy.

Definer hva et mislykket oppslag betyr

Et tomt eller mislykket poolsvar bør ikke lydløst fjerne proxy-metadataene og tillate en direkte forespørsel. Velg et eksplisitt utfall: vent innenfor oppgavens budsjett, feil, eller bruk et godkjent bufret endpoint.

Hold også pool-API-ens egen rute fri. Hvis det er en intern tjeneste, kan det å sende dens private vertsnavn gjennom nettopp den proxyen den hjelper med å velge skape en sirkulær avhengighet.

Når oppdagelsen fungerer uten å blokkere urelatert arbeid, undersøk den vanlige proxy-transaksjonen. Det er separate reparasjoner, og timingen deres fortjener separate felt i loggen.