Прокси на месяц или на сутки: как подобрать срок доступа к пулу под задачу

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

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

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

Что входит в срок доступа и за что считается пакет

В пакет входит доступ к списку адресов и две привязки по адресу машины. Список отдаётся в двух формах: IP:PORT для работы с привязанной машины и IP:PORT:LOGIN:PASS для работы по паре логин и пароль. Забрать его можно ссылкой или файлом, ссылка при каждом обращении отдаёт актуальный состав. Я держу у себя запрос к этой ссылке в начале каждого прогона, чтобы парсер стартовал с сегодняшним списком.

Потоки считаются на пакет. На обычных пакетах лимит 1000 одновременных потоков, на корпоративном месячном до 3000. Здесь одна деталь, о которую спотыкаются при закупке второго пакета: потоки между пакетами не складываются. Два пакета на одном аккаунте дают две независимые квоты, каждая живёт в своих границах. Если к пакету привязаны два адреса машины, квота делится между ними пополам: по 500 потоков на каждую машину при обычном пакете.

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

Дальше по тексту слово «срок» означает срок доступа к пулу. Формулировка точнее описывает происходящее: аккаунт получает право работать с пулом в течение периода, а состав адресов на выходе меняется сам, без участия клиента.

Бесплатный тест до 2 часов: что успеваю проверить за окно

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

Сначала забираю список и проверяю один порт вручную, без обвязки:

curl -x http://LOGIN:PASS@IP:PORT -s -o /dev/null \
     -w "%{http_code} %{time_total}\n" https://httpbin.org/ip

Дальше тот же порт по SOCKS5, с разрешением имён на стороне порта:

curl -x socks5h://LOGIN:PASS@IP:PORT -s -o /dev/null \
     -w "%{http_code} %{time_total}\n" https://httpbin.org/ip

Два ответа с кодом 200 говорят, что доступ живой и оба протокола на месте. Теперь начинается интересное. Я запускаю настоящий парсер на выборке из 200 страниц целевой площадки, с той же связкой заголовков, куками и таймаутами, которые пойдут в работу. Смотрю на три вещи: доля кодов 200, среднее время ответа, поведение при повторе одного и того же URL через минуту.

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

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

Сутки, неделя и месяц: чем отличается организация работы

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

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

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

Как я раскладываю задачи по срокам и потокам

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

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

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

Плотность обращений и скорость: почему на длинном сроке выгодно идти ровно

Площадка смотрит на плотность обращений, то есть на число запросов в единицу времени с одного источника и по одному шаблону поведения. Общий объём за месяц её волнует слабо. Именно поэтому один и тот же объём страниц собирается совершенно по-разному в зависимости от того, сколько времени у вас есть.

Я мерил это на съёме карточек с одной торговой площадки. Восемьдесят тысяч карточек за сутки при трёхстах потоках дали 21 процент отказов и две паузы, когда приёмная сторона начала отвечать заглушками. Те же восемьдесят тысяч, разложенные на 30 суток по расписанию с сорока потоками, дали 3 процента отказов и ни одной паузы. Итоговый набор данных получился одинаковый, работы по разбору логов во втором случае вышло в разы меньше.

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

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

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

Разовый прогон: как уложить сбор в срок пакета

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

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

Если результат укладывается в одно ночное окно, беру сутки. Если счёт идёт на двое или трое суток, беру неделю с запасом, потому что разовый прогон почти никогда не проходит с первого раза начисто. Разметка меняется на части страниц, часть целей отдаёт пустой ответ, где-то всплывает проверочное окно. Запас по сроку закрывает всё это без нервов и без повторной закупки.

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

Ежедневный съём: расписание вместо рывков

Постоянный съём устроен иначе. Источник тот же изо дня в день, объём за сутки небольшой, важна непрерывность ряда. Цены конкурентов, позиции в выдаче, новые отзывы, статус объявлений. Пропущенные сутки портят ряд сильнее, чем сотня несобранных карточек.

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

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

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

Настройка один раз и пересборка каждый цикл

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

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

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

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

Несколько пакетов на одном аккаунте под разные задачи

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

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

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

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

Продление без перерыва в работе

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

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

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

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

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

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

Соседние заметки этого раздела продолжают тему с других сторон. Разбор версий протокола и совместимости площадок собран в материале IPv4 или IPv6, там же про то, какие сервисы принимают шестую версию на входе. Как площадки читают репутацию адреса и чем отличается белый адрес от серого, разложено в заметке белый или серый IP. Номера портов под HTTP и SOCKS5 и способы проверить их доступность описаны в статье порт прокси-сервера. Из практического раздела по теме ближе всего лимит потоков и расчёт нагрузки, где потоки посчитаны подробно, с формулами под размер пакета.