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

Для гіпотетичного акаунта, що дозволяє щонайбільше 20 одночасних запитів, залиште запас і задайте глобальний ліміт завантажувача краулера:

CONCURRENT_REQUESTS = 16

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

Врахуйте в розрахунку й інших краулерів. Два незалежні краулери, кожному з яких дозволено 16 запитів, разом можуть перевищити спільну квоту в 20. Розподіліть бюджет навмисно або встановіть спільний ліміт там, де ці клієнти сходяться.

Також з'ясуйте, що саме рахує постачальник. HTTP-запити, відкриті TCP-з'єднання, активні тунелі та запити за секунду — різні величини. Постійні з'єднання й мультиплексування можуть розвести їхні показники. Тому налаштування паралельності запитів не є повним обмежувачем з'єднань чи швидкості.

Зберігайте темп цільового сайту як окреме обмеження. Менша паралельність або затримка завантаження можуть залишатися доречними для окремого призначення навіть тоді, коли проксі-акаунт має невикористану потужність.

Схожі статті