Прокси для мониторинга цен на маркетплейсах: сколько адресов нужно на каталог

Что вы запрашиваете на самом деле

Цена и наличие обычно приходят не в HTML страницы, а отдельным ответом в формате JSON — тем же, который использует сама витрина. Это заметно меняет расчёт: такие ответы легче и быстрее, значит на одну карточку уходит меньше времени и меньше трафика, а частота запросов при том же темпе получается выше.

Считаем объём

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

запросов в час = позиции × обновлений в час

10 000 позиций, раз в час      -> 10 000 запросов/час  ≈ 2,8 в секунду
10 000 позиций, каждые 15 мин   -> 40 000 запросов/час  ≈ 11 в секунду
10 000 позиций, каждые 5 мин    -> 120 000 запросов/час ≈ 33 в секунду

Дальше из темпа получается число потоков: умножьте запросы в секунду на среднее время ответа. При 11 запросах в секунду и ответе 0,7 секунды нужно около 8 одновременных подключений в среднем, и с запасом на повторы и медленные ответы — от 50 до 100.

Потолок задаёт частота на один адрес

Здесь главное отличие от обычного парсинга. Ограничение выставляется на адрес, а не на ваш аккаунт, поэтому увеличение числа потоков без роста пула адресов просто ускорит получение отказов. Ротационный пул решает это тем, что распределяет тот же темп по многим адресам: на каждый приходится небольшая доля запросов.

Какой режим ротации выбрать

• Обход каталога по списку артикулов — ротация на каждый запрос: обращения независимы, и чем шире распределение, тем лучше.
• Карточка, которая отдаётся только внутри сессии — ротация по таймеру: сначала выдаётся cookie, потом по нему открывается контент.
• Смешанный сбор — два тарифа с разными режимами дешевле, чем один компромиссный.

Ограничитель темпа, а не только потоков

Типичная ошибка — выставить 50 потоков и отпустить. Пул отработает залпом: пятьдесят запросов уйдут одновременно, упрутся в лимит частоты, и дальше пойдут отказы. Нужны два ограничителя: сколько соединений одновременно и сколько запросов в секунду.

import threading, requests
from concurrent.futures import ThreadPoolExecutor

THREADS = 50          # не больше числа потоков в тарифе
RATE_PER_SECOND = 3   # запросов в секунду на весь пул, подбирается опытом

gate = threading.Semaphore(THREADS)
ticket = threading.Semaphore(RATE_PER_SECOND)

def fetch(sku, session):
    # Два ограничителя: сколько соединений одновременно и как часто вообще.
    # Без второго 50 потоков дадут залп и 429, даже если тариф это позволяет.
    with gate, ticket:
        return session.get(f"https://example.com/api/card/{sku}", timeout=(5, 30))

session = requests.Session()
with ThreadPoolExecutor(max_workers=THREADS) as pool:
    for sku in range(1000):
        pool.submit(fetch, sku, session)

Что делать при отказах

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

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

Как понять, что темп уже избыточен

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

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

Что считать успехом

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

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

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