Сколько потоков нужно парсеру: расчёт на практике

Что такое поток

Поток — это одно одновременно открытое подключение к прокси. Тариф на 50 потоков означает, что в любой момент времени активны не больше пятидесяти подключений. Сколько запросов пройдёт через них за сутки — не ограничено: пятьдесят потоков за день могут дать и тысячу запросов, и миллион.

Формула

Нужное число потоков считается из трёх величин: сколько запросов сделать, за какое время и сколько в среднем занимает один ответ.

потоки = запросы × время_ответа / срок

Пример: 10 000 карточек, ответ 0,7 с, обойти за час.
10 000 × 0,7 / 3600 ≈ 2 потока в среднем.

Цифра выглядит неожиданно маленькой, и это нормально: при часовом окне нагрузка размазана. Но среднее — не то, на что стоит закладываться.

Почему берут с запасом

Средний расчёт не учитывает три вещи, которые в реальности съедают производительность.

• Повторы: часть запросов вернётся ошибкой и уйдёт в retry, а это дополнительные подключения.
• Разброс времени ответа: медленные страницы держат поток занятым в разы дольше среднего.
• Неравномерность: сбор редко идёт ровным потоком, обычно есть пики в начале и в конце.

Практический множитель — от пяти до десяти к расчётному среднему. Для примера выше это 10–20 потоков, и тариф Starter-1 на 50 потоков закрывает задачу с большим запасом.

Когда потоков действительно нужно много

Число растёт не от каталога, а от сжатия срока. Те же 10 000 карточек за пять минут вместо часа — это уже около 25 потоков в среднем и 150–250 с запасом. Ускорение в двенадцать раз требует во столько же раз больше подключений.

10 000 карточек, ответ 0,7 с:
  за 1 час   → ~2 в среднем   → тариф на 50 потоков
  за 10 мин  → ~12 в среднем  → тариф на 100–200
  за 5 мин   → ~25 в среднем  → тариф на 300–500

Как проверить, что упёрлись

Если увеличение потоков в настройках софта не ускоряет сбор — узкое место не в тарифе. Проверьте время ответа целевого сайта и долю повторов: чаще всего именно они, а не лимит подключений, определяют итоговый темп.

Обратный признак — часть подключений стабильно ждёт очереди, а загрузка канала невысокая. Это и есть исчерпанный лимит потоков, и тариф стоит поднять.

Почему число потоков в парсере не равно числу соединений

Это главный источник расхождения между настройкой и тем, что видит прокси. Соединение с включённым keep-alive обслуживает много запросов подряд, поэтому десять рабочих потоков могут держать меньше десяти сокетов. Но бывает и наоборот, и второй случай неприятнее.

import requests
from requests.adapters import HTTPAdapter

session = requests.Session()
session.mount("https://", HTTPAdapter(
    pool_maxsize=50,     # не меньше числа рабочих потоков
    pool_block=True,     # лишние потоки ждут, а не открывают сокет мимо пула
))

# Что происходит при pool_block=False (значение по умолчанию):
# соединений сверх pool_maxsize будет создано столько, сколько попросят,
# но после использования они НЕ сохраняются. То есть 50 потоков на пуле
# в 10 соединений дадут постоянную пересборку — и прокси увидит
# не 10 сессий, а поток новых подключений.

Смысл в том, что пул соединений и число потоков — независимые настройки, и когда пул меньше, каждое лишнее соединение создаётся заново под запрос и закрывается после. Для прокси это выглядит как множество коротких сессий вместо нескольких долгих, и лимит расходуется быстрее, чем вы рассчитывали.

• Пул меньше числа потоков — постоянная пересборка соединений и лишний расход лимита.
• HTTP/2 мультиплексирует много запросов в один сокет: соединений будет меньше, чем запросов.
• Редиректы и TLS-рукопожатия добавляют подключения, которых нет в вашем счёте.
• Повтор после разрыва соединения открывает новый сокет, а не переиспользует прежний.

В Scrapy это считается иначе

Здесь стоит проверить настройки перед расчётом. Общий предел задаётся одной величиной, но действует ещё и ограничение на домен, и с некоторых версий шаблон нового проекта прописывает довольно осторожные значения по умолчанию — по одному запросу на домен и секундную задержку.