Blokujúca požiadavka na proxy pool môže zaseknúť Scrapy

Prehliadač má nakonfigurovaných dosť súbežných požiadaviek. Napriek tomu sa zastaví vždy, keď požiada proxy pool o ďalšiu adresu. Pridanie ďalších proxy túto pauzu nemení.

Bežný vzor middleware volá requests.get(pool_url) vnútri process_request(). Ide o synchrónnu sieťovú operáciu na ceste, ktorá má spolupracovať s asynchrónnym enginom Scrapy. Kým volanie čaká, môže zdržiavať nesúvisiacu prácu v tom istom vlákne slučky udalostí.

V úlohe sú dve požiadavky

Jedna požiadavka získa koncový bod od služby poolu. Druhá použije tento koncový bod na kontakt s cieľom. Merajte ich a vykazujte oddelene. Pomalé API poolu môže spôsobiť, že každý vybraný proxy bude vyzerať pomalý ešte predtým, než sa k nemu aplikácia pripojí.

Použite integráciu asynchrónneho zisťovania podporovanú nainštalovanou verziou Scrapy, alebo získajte a obnovujte obmedzenú lokálnu množinu koncových bodov mimo kritickej cesty každej požiadavky. Ak treba blokujúcu prácu presunúť, dajte tomuto vykonávateľovi vlastné limity a spracovanie časových limitov; neobmedzený front len presúva oneskorenie.

Nevydávajte automaticky ďalšie volanie zisťovania pre každú požiadavku. Krátkodobá cache alebo prenajatá dávka môžu znížiť závislosť od služby poolu, ak ich životnosť zodpovedá skutočnej politike koncových bodov služby.

Definujte, čo znamená neúspešné hľadanie

Prázdna alebo neúspešná odpoveď poolu by nemala ticho odstrániť metadáta proxy a povoliť priamu požiadavku. Zvoľte výslovný výsledok: čakať v rámci rozpočtu úlohy, zlyhať alebo použiť schválený koncový bod z cache.

Udržujte čistú aj vlastnú trasu API poolu. Ak je to interná služba, odosielanie jej súkromného názvu hostiteľa práve cez ten proxy, ktorý pomáha ho vybrať, môže vytvoriť kruhovú závislosť.

Keď zisťovanie funguje bez blokovania nesúvisiacej práce, preskúmajte bežnú proxy transakciu. To sú samostatné opravy a ich čas si zaslúži samostatné polia v logu.