En blockerande proxy-pool-uppslagning kan stoppa Scrapy

Crawlaren har gott om samtidiga förfrågningar konfigurerade. Ändå pausar den varje gång den ber proxy-poolen om en annan adress. Fler proxys påverkar inte den pausen.

Ett vanligt middleware-mönster anropar requests.get(pool_url) inuti process_request(). Det är en synkron nätverksoperation på en väg som förväntas samarbeta med Scrapys asynkrona motor. Medan anropet väntar kan det hålla upp orelaterat arbete på samma händelseloop-tråd.

Det finns två förfrågningar i jobbet

En förfrågan hämtar en endpoint från pooltjänsten. Den andra använder endpointen för att kontakta destinationen. Mät och rapportera dem separat. Ett långsamt pool-API kan få varje vald proxy att verka långsam innan applikationen ens har anslutit till den.

Använd en asynkron upptäcktsintegration som den installerade Scrapy-versionen stöder, eller hämta och uppdatera en begränsad lokal endpoint-uppsättning utanför den kritiska vägen per förfrågan. Om blockerande arbete måste flyttas, ge den exekutorn egna gränser och tidsgränshantering; en obegränsad kö flyttar bara fördröjningen.

Skicka inte automatiskt ännu ett upptäcktsanrop för varje förfrågan. En kortlivad cache eller en leasad batch kan minska beroendet av pooltjänsten, förutsatt att livslängden passar tjänstens faktiska endpoint-policy.

Definiera vad en misslyckad uppslagning betyder

Ett tomt eller misslyckat poolsvar bör inte tyst ta bort proxy-metadatan och tillåta en direkt förfrågan. Välj ett uttryckligt utfall: vänta inom uppgiftens budget, misslyckas eller använd en godkänd cachad endpoint.

Håll också pool-API:ns egen rutt fri. Om det är en intern tjänst kan det att skicka dess privata värdnamn genom just den proxy som hjälper till att välja den skapa ett cirkulärt beroende.

När upptäckten fungerar utan att blockera orelaterat arbete, undersök den vanliga proxy-transaktionen. Det är separata reparationer, och deras tidsmätning förtjänar separata fält i loggen.