Eit blokkerande proxy-pool-oppslag kan stoppa Scrapy

Kravlaren har rikeleg med samtidige førespurnader konfigurert. Likevel stoppar han kvar gong han ber proxy-poolen om ei anna adresse. Å leggje til fleire proxyar endrar ikkje den pausen.

Eit vanleg middleware-mønster kallar requests.get(pool_url) inne i process_request(). Det er ein synkron nettverksoperasjon på ei bane som er venta å samarbeide med den asynkrone motoren til Scrapy. Medan kallet ventar, kan det halde tilbake urelatert arbeid på same hendingsløkkjetråd.

Det er to førespurnader i jobben

Éin førespurnad hentar eit endpoint frå pooltenesta. Den andre brukar det endpointet til å kontakte destinasjonen. Mål og rapporter dei kvar for seg. Ein treg pool-API kan få kvar vald proxy til å verke treg før applikasjonen i det heile har kopla til han.

Bruk ein asynkron oppdagingsintegrasjon som den installerte Scrapy-versjonen støttar, eller hent og oppdater eit avgrensa lokalt endpoint-sett utanfor den kritiske bana per førespurnad. Viss blokkerande arbeid må flyttast, gje den utføraren eigne grenser og handsaming av tidsavbrot; ein ubegrensa kø flyttar berre forseinkinga.

Ikkje send automatisk endå eit oppdagingskall for kvar førespurnad. Ein kortvarig cache eller ein leigd batch kan redusere avhengnaden av pooltenesta, føresett at levetida passar til den faktiske endpoint-politikken til tenesta.

Definer kva eit mislukka oppslag tyder

Eit tomt eller mislukka poolsvar bør ikkje lydlaust fjerne proxy-metadataa og tillate ein direkte førespurnad. Vel eit uttrykkeleg utfall: vent innanfor budsjettet til oppgåva, mislukk, eller bruk eit godkjent bufra endpoint.

Hald òg den eigne ruta til pool-API-en fri. Viss det er ei intern teneste, kan det å sende det private vertsnamnet hennar gjennom nettopp den proxyen ho hjelper med å velje skape ein sirkulær avhengnad.

Når oppdaginga verkar utan å blokkere urelatert arbeid, undersøk den vanlege proxy-transaksjonen. Det er separate reparasjonar, og tidtakinga deira fortener separate felt i loggen.