Прокси для Key Collector: съём частотности и подсказок без остановок

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

Сколько адресов уходит на проект под размер семантики

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

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

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

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

Отдельно про размер семантики, который приходит от заказчика в виде «соберите всё по теме». Такие проекты вырастают в процессе: стартовое ядро на 500 фраз после расширения подсказками превращается в 40 000 строк, и весь расчёт по адресам приходится пересматривать посреди работы. Поэтому я снимаю подсказки первым этапом, смотрю, во что вырос список, и только потом считаю адреса под частотность.

Частотность и подсказки: разная нагрузка на один пул

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

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

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

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

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

Где в программе вносится список адресов

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

Формат строки программа принимает в нескольких видах. Простой адрес с портом подходит, когда доступ выдан по привязке своей машины в кабинете. Строка с логином и паролем подходит, когда пул отдан в формате с авторизацией.

203.0.113.10:8080
203.0.113.11:8080:kc41:s8Kd2pQr
socks5://203.0.113.12:1080
socks5://203.0.113.13:1080:kc41:s8Kd2pQr

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

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

while read -r line; do
  ip=$(echo "$line" | cut -d: -f1)
  out=$(curl -s -m 8 --proxy "http://$line" https://api.ipify.org)
  printf '%-18s -> %s\n' "$ip" "${out:-нет ответа}"
done < pool.txt

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

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

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

Потоки: сколько ставить на адрес и как делится лимит пакета

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

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

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

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

Отдельно про соотношение потоков и пауз. Эти две настройки работают в связке, и менять их по отдельности бессмысленно. Удвоение потоков при той же паузе удваивает частоту обращений с адреса, поэтому при переходе с двух потоков на четыре паузу нужно тоже удваивать. Я держу в уме простое произведение: потоки, делённые на паузу в секундах, дают обращений в секунду с одного адреса. Два потока при паузе 12 секунд это 0,17 обращения в секунду, десять обращений в минуту. Такой темп источник статистики принимает ровно.

Паузы и задержки под каждый источник

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

Значения я подбирал экспериментально и с тех пор менял их незначительно. В таблице ниже собран мой рабочий набор для приватных серверных адресов на выделенных портах.

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

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

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

Капча в Key Collector и связка адресов с сервисом распознавания

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

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

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

Настройки -> Антикапча
  [x] Использовать сервис распознавания
  Поставщик:        выбранный сервис
  Ключ доступа:     3f9c...
  Тип капчи:        изображение
  Повторов на одну: 2
  Пауза перед повтором: 20 сек

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

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

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

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

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

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

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

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

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

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

Как разложить проект по потокам и группам

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

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

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

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

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

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

Ночной прогон на 100 000 ключей от старта до утра

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

Вечером первого дня я собираю группы и прогоняю проверку списка через curl, чтобы отсеять строки с опечатками. Дальше расставляю флажки прокси у каждого парсера, разношу адреса по аккаунтам сервиса статистики построчно, проверяю ключ сервиса распознавания и его баланс. Ставлю паузы по таблице: 10-14 секунд на частотность в кавычках, 0,3 секунды на подсказки, задержку после сбоя в 90 секунд. Запускаю первый пакет вручную и десять минут смотрю в журнал. Десять минут наблюдения экономят всю ночь.

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

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

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

Смежные материалы раздела дополняют картину с других сторон: разбор Dolphin Anty и подмены отпечатка пригодится, когда сбор идёт из браузерных профилей, A-Parser и многопоточный сбор показывает ту же арифметику потоков на другом инструменте, а ZennoPoster и работа по шаблонам закрывает автоматизацию действий поверх собранных данных. Из раздела о сборе данных ближе всего страница про капчу при сборе данных: там подробно разобраны типы проверок и порядок подключения распознавания.