Сколько адресов нужно под задачу: считаем потоки и частоту обращений

Величина для расчёта здесь одна: число одновременных потоков и частота обращений к целевому сайту. Количество адресов задаётся пакетом целиком, доступ открывается ко всему пулу примерно из 12 000 активных строк, ротация внутри пула идёт автоматически, поэтому штуки считать не приходится.

Дальше разобрана арифметика. Как из объёма прогона получить требуемую скорость, как из скорости и среднего времени отклика получить число потоков, какой лимит записан в стандартном пакете и в корпоративном, почему потоки разных пакетов складывать нельзя. В конце три сценария с цифрами: сбор прайсов поставщиков, съём позиций по семантике и работа с несколькими рабочими кабинетами.

Почему вопрос «сколько адресов» упирается в потоки

Формулировка «мне нужно тридцать прокси» пришла из схемы, где покупатель получает короткий фиксированный список строк и раздаёт их своим процессам руками. У нас пакет открывает доступ ко всему пулу сразу, список забирается ссылкой или файлом в форматах IP:PORT и IP:PORT:LOGIN:PASS, обновляется он в реальном времени. Ограничивает работу лимит одновременных потоков, записанный в пакете.

Поток это соединение, которое программа держит открытым в конкретный момент времени. A-Parser показывает эту величину в настройках задания, ZennoPoster в свойствах проекта, Key Collector в параметрах сбора, обычный curl в связке с xargs -P принимает её флагом. Когда мы считаем нагрузку, мы смотрим именно в это поле. Всё остальное производные: сколько страниц пройдено за час, сколько времени займёт полный прогон, упрётся ли софт в потолок пакета.

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

Считаем требуемую скорость: страницы делим на часы прогона

Первая величина считается за минуту. Берём число целевых страниц за один прогон, делим на количество часов, которые отведены под работу, получаем требуемую скорость в запросах за час. Никаких коэффициентов на этом шаге не вводим, они появятся дальше.

Отдельно отмечаем два момента. Первый: страницы считаются по факту запросов, число товаров тут обманывает, потому что карточка часто требует двух обращений (сама страница плюс запрос к внутреннему методу с ценой или остатком). Второй: в число входят повторные попытки. Если по опыту прошлых прогонов доля повторов держится около десяти процентов, объём умножается на 1.1 до всякого деления.

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

Из скорости и времени отклика получаем число потоков

Вторая величина выводится из первой. Переводим запросы в час в запросы в секунду, умножаем на среднее время отклика целевого домена в секундах и получаем минимальное число потоков, при котором заданная скорость держится. Формула короткая, проверяется на калькуляторе.

# потоки = запросы в секунду * среднее время отклика
# запросы в секунду = обращения / (часы * 3600)

python3 - <<'PY'
pages, hours, latency = 40000, 8, 1.2
rps = pages / (hours * 3600)
print(round(rps, 2), "запросов в секунду")
print(round(rps * latency, 1), "потоков по формуле")
PY

Среднее время отклика берём измерением. Один вызов curl через пул на реальный целевой адрес показывает полное время запроса, двадцать таких вызовов подряд дают среднее, по которому уже можно считать:

for i in $(seq 1 20); do
  curl -o /dev/null -s -w "%{time_total}\n" \
    -x http://185.24.87.14:8000 https://example.com/catalog/page/1
done | awk '{s+=$1} END {print "среднее:", s/NR, "с"}'

Правая колонка отличается от расчётной в три раза с округлением вверх, и запас берётся осознанно. Часть соединений в любой момент висит в ожидании ответа, часть страниц отдаётся медленнее среднего, часть обращений уходит на повтор после таймаута, и без запаса реальная скорость проседает ниже плановой уже на второй час прогона. Тройной коэффициент выдерживает эти три источника задержки одновременно и при этом далеко не подходит к потолку пакета.

Лимит потоков в пакете: 1000, 3000 и почему они не складываются

Стандартные пакеты дают до 1000 одновременных потоков, корпоративный месяц поднимает лимит до 3000. Величина записана в самом пакете и работает поверх всех настроек софта: программа может просить сколько угодно соединений, наружу пройдёт столько, сколько разрешено.

На лимит влияет привязка. В пакет входит одновременная привязка 2 адресов со свободной сменой в настройках кабинета, и при двух привязанных адресах общее число потоков делится между ними пополам. Пакет на 1000 потоков при двух привязках отдаёт по 500 на каждую машину. Это ровно та деталь, которую забывают при расчёте: администратор считал нагрузку по полной цифре, а рабочая машина упирается в половину и логи наполняются отказами.

Потоки разных пакетов не складываются. Два стандартных пакета на одном аккаунте дают два независимых лимита по 1000, каждый работает сам по себе, общей суммы в две тысячи потоков из них не получится. Причина в устройстве учёта: лимит привязан к пакету и к адресу, с которого идут запросы, поэтому один прогон с одной машины видит потолок одного пакета.

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

Ротация внутри пула из 12 000 адресов снимает вопрос количества

Пул держит около 12 000 активных адресов в сутки, список обновляется в реальном времени, ротация внутри пула автоматическая. Практический смысл этой цифры такой: запросы одного прогона расходятся по множеству адресов и подсетей сами, без ручной раздачи строк по потокам и без отдельной логики перебора в софте.

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

География пула это микс со всего мира, адреса приходят из 200+ стран. Для сбора открытых данных, съёма выдачи и разведения рабочих профилей такая схема даёт разнообразие подсетей без ручной настройки: соседние запросы уходят из разных диапазонов, и целевой сайт видит их как обращения из разных сетей.

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

Сбор прайсов поставщиков: расчёт на цифрах

Магазин снимает прайсы у шести поставщиков, суммарно 40 000 карточек, окно ночное с полуночи до восьми утра. Половина поставщиков отдаёт цену прямо в разметке карточки, вторая половина требует дополнительного обращения к внутреннему методу, поэтому реальных запросов выходит около 60 000. Делим на 8 часов, получаем 7 500 запросов в час.

Отклик по измерению держится около 1.8 секунды, площадки крупные и отвечают ровно. Запросов в секунду выходит 2.08, потоков по формуле около четырёх, в софте ставим 15. Прогон укладывается в окно с запасом, и даже при просадке отклика вдвое скорость остаётся плановой. Лимит стандартного пакета здесь используется на полтора процента, и это нормальная картина для одиночного парсера.

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

Съём позиций: расчёт на цифрах

Съём выдачи считается иначе, потому что единица работы здесь проверка одного ключа в одной поисковой системе. Семантика на 4 000 запросов, глубина проверки три страницы выдачи, две поисковые системы. Обращений получается 4 000 умножить на 3 и на 2, итого 24 000 за один съём.

Съём делается раз в неделю и растягивается на 6 часов, чтобы частота обращений к выдаче держалась ровной. Требуемая скорость 4 000 запросов в час, это 1.11 в секунду. Отклик у страниц выдачи заметно выше каталожного, около 2.5 секунды с учётом редиректов. Потоков по формуле выходит 3, в софте ставим 12.

Здесь важнее ровность, чем максимум. Key Collector и близкие программы дают задать паузу между обращениями и разброс этой паузы, и связка «умеренные потоки плюс разброс» держит съём стабильнее, чем попытка выжать всю семантику за сорок минут на двухстах потоках. Настройки для этой программы разобраны на странице про работу Key Collector через пул.

Отдельно считаем случай агентства. Двадцать проектов, средняя семантика по 1 500 ключей, съём раз в неделю по всем сразу, окно двое суток. Обращений 20 умножить на 1 500, на 3 и на 2, итого 180 000. При 48 часах это 3 750 запросов в час, потоков по формуле около трёх, в софте 12 при последовательном обходе проектов. Если же агентство запускает проекты параллельно на разных серверах, каждый сервер получает свой пакет и свой лимит, и суммарная нагрузка распределяется без упора в потолок. Тонкости съёма разобраны отдельно в материале про позиции и работу с выдачей.

Несколько рабочих кабинетов: счёт по профилям

Третий сценарий устроен принципиально иначе. В работе с кабинетами и профилями антидетект-браузера нагрузка низкая, обращений мало, зато соединения живут долго: открытая вкладка держит поток всё время, пока сотрудник работает. Здесь число потоков считается по числу одновременно открытых профилей, умноженному на среднее количество параллельных соединений браузера.

Один профиль антидетект-браузера в активной работе держит от 6 до 12 соединений: сама страница, статика, запросы к внутренним методам интерфейса, фоновые опросы. Берём верхнюю границу. Команда из пяти человек, у каждого по три открытых профиля, итого 15 профилей и около 180 потоков в пике. Стандартный лимит это покрывает с большим запасом.

Четвёртая строка таблицы показывает ту самую ловушку с делением. Сорок профилей дают 480 потоков, лимит при двух привязанных адресах составляет 500 на машину, и запас исчезает полностью: любая всплывающая нагрузка вроде массовой загрузки медиа упирается в потолок. Выход простой: оставить одну привязку на время работы отдела либо перейти на корпоративный пакет. Командам, где профили разведены по сотрудникам, подходит приватный доступ к пулу для рабочей группы, а сам порядок разведения кабинетов разобран в материале про несколько кабинетов одной компании.

Как проверить расчёт за два тестовых часа

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

Порядок запуска короткий. Выбрать тип прокси под свой софт, зарегистрироваться в кабинете, отправить запрос теста из меню, указать свой адрес в настройках, активировать доступ, затем написать оператору логин и тип прокси. Пакет после оплаты включается примерно за 5 минут, тестовый доступ открывается тем же порядком.

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

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

Частые вопросы

Что входит в прокси-пул и сколько там адресов?

В пуле около 12 000 активных IPv4 и SOCKS5, онлайн держится в этом районе в сутки, список адресов обновляется в режиме реального времени. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000. Доступ к пулу открыт только клиентам сервиса.

Есть ли лимиты по потокам и как они считаются?

У каждого пакета свой лимит. При двух привязанных адресах общее число потоков делится между ними пополам, поэтому пакет на 1000 потоков отдаёт по 500 на машину. Пакеты по потокам не складываются: два пакета работают как два независимых лимита. Аккаунты с подозрительно высокой активностью ставятся на паузу до выяснения.

Сколько пакетов можно держать на одном аккаунте?

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

Как понять, что рассчитанного лимита хватит под мою задачу?

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

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