Блокирајуће тражење прокси пула може зауставити Scrapy

Пузалац има довољно конфигурисаних истовремених захтева. Ипак стане кад год од прокси пула затражи другу адресу. Додавање више проксија не дира то заустављање.

Уобичајен образац middleware-а позива requests.get(pool_url) унутар process_request(). То је синхрона мрежна операција на путањи која треба да сарађује са асинхроним Scrapy мотором. Док позив чека, може задржати неповезани рад на истој нити петље догађаја.

У послу су два захтева

Један захтев добија крајњу тачку од сервиса пула. Други користи ту крајњу тачку за контакт са одредиштем. Мерите их и извештавајте одвојено. Спор API пула може учинити сваки изабрани прокси спорим пре него што се апликација уопште повеже са њим.

Користите интеграцију асинхроног откривања коју подржава инсталирана верзија Scrapy-ја или прибавите и освежавајте ограничен локални скуп крајњих тачака изван критичне путање сваког захтева. Ако се блокирајући рад мора пребацити, дајте том извршиоцу сопствена ограничења и руковање временским ограничењима; неограничен ред само премешта кашњење.

Не издајте аутоматски још један позив откривања за сваки захтев. Краткотрајни кеш или изнајмљена серија могу смањити зависност од сервиса пула, под условом да њихов животни век одговара стварној политици крајњих тачака тог сервиса.

Дефинишите шта значи неуспешно тражење

Празан или неуспешан одговор пула не сме тихо уклонити метаподатке проксија и дозволити директан захтев. Одаберите изричит исход: чекање унутар буџета задатка, неуспех или коришћење одобрене кеширане крајње тачке.

Одржавајте и сопствену руту API-ја пула чистом. Ако је то интерни сервис, слање његовог приватног имена хоста кроз управо онај прокси који помаже да се изабере може створити кружну зависност.

Кад откривање ради без блокирања неповезаног рада, прегледајте обичну прокси трансакцију. То су одвојене поправке и њихово време заслужује одвојена поља у дневнику.