Blokující dotaz na proxy pool může zaseknout Scrapy

Prohledávač má nakonfigurováno dost souběžných požadavků. Přesto se zastaví, kdykoli požádá proxy pool o další adresu. Přidání dalších proxy tento výpadek neřeší.

Běžný vzor middleware volá requests.get(pool_url) uvnitř process_request(). Jde o synchronní síťovou operaci na cestě, která má spolupracovat s asynchronním enginem Scrapy. Zatímco volání čeká, může zdržovat nesouvisející práci na stejném vlákně smyčky událostí.

V úloze jsou dva požadavky

Jeden požadavek získá koncový bod od služby poolu. Druhý tento koncový bod použije ke spojení s cílem. Měřte je a vykazujte odděleně. Pomalé API poolu může způsobit, že každá vybraná proxy vypadá pomalá, ještě než se k ní aplikace připojí.

Použijte integraci asynchronního zjišťování podporovanou nainstalovanou verzí Scrapy, nebo si opatřete a obnovujte omezenou místní sadu koncových bodů mimo kritickou cestu jednotlivých požadavků. Pokud je třeba blokující práci přesunout, dejte tomuto exekutoru vlastní limity a zpracování časových limitů; neomezená fronta jen přesouvá zpoždění.

Nevydávejte automaticky další volání zjišťování pro každý požadavek. Krátkodobá cache nebo pronajatá dávka může snížit závislost na službě poolu, pokud její životnost odpovídá skutečné politice koncových bodů služby.

Definujte, co znamená neúspěšné hledání

Prázdná nebo neúspěšná odpověď poolu by neměla tiše odstranit metadata proxy a povolit přímý požadavek. Zvolte výslovný výsledek: čekat v rámci rozpočtu úlohy, selhat, nebo použít schválený koncový bod z cache.

Udržujte čistou i vlastní trasu API poolu. Je-li to interní služba, posílání jejího soukromého hostname přes právě tu proxy, která pomáhá ji vybrat, může vytvořit kruhovou závislost.

Jakmile zjišťování funguje bez blokování nesouvisející práce, prozkoumejte běžnou proxy transakci. To jsou samostatné opravy a jejich časování si zaslouží samostatná pole v logu.