Блокуючий запит до пулу проксі може зупинити Scrapy

Сканер має достатньо налаштованих одночасних запитів. І все ж він зупиняється щоразу, коли просить у пулу проксі чергову адресу. Додавання нових проксі цієї зупинки не змінює.

Поширений шаблон middleware викликає requests.get(pool_url) усередині process_request(). Це синхронна мережева операція на шляху, який має взаємодіяти з асинхронним рушієм Scrapy. Поки виклик чекає, він може стримувати сторонню роботу в тому самому потоці циклу подій.

У завданні два запити

Один запит отримує кінцеву точку від служби пулу. Інший використовує цю точку для зв'язку з пунктом призначення. Вимірюйте й звітуйте про них окремо. Повільний API пулу може зробити кожен вибраний проксі повільним ще до того, як застосунок до нього підключився.

Використовуйте інтеграцію асинхронного виявлення, яку підтримує встановлена версія Scrapy, або отримуйте й оновлюйте обмежений локальний набір кінцевих точок поза критичним шляхом кожного запиту. Якщо блокуючу роботу треба винести, дайте цьому виконавцю власні ліміти й обробку тайм-аутів; необмежена черга лише переносить затримку.

Не робіть автоматично ще один виклик виявлення на кожен запит. Короткочасний кеш або орендована партія можуть зменшити залежність від служби пулу, якщо строк їхнього життя відповідає реальній політиці кінцевих точок служби.

Визначте, що означає невдалий пошук

Порожня або невдала відповідь пулу не повинна мовчки видаляти метадані проксі й дозволяти прямий запит. Виберіть явний результат: чекати в межах бюджету завдання, зазнати невдачі або використати схвалену кешовану кінцеву точку.

Тримайте вільною й власну маршрутизацію API пулу. Якщо це внутрішня служба, надсилання її приватного імені хоста через той самий проксі, який допомагає її вибрати, може створити циклічну залежність.

Коли виявлення працює, не блокуючи сторонню роботу, дослідіть звичайну транзакцію через проксі. Це окремі виправлення, і їхній час заслуговує на окремі поля в журналі.