KeyAssort настройка прокси: список адресов, потоки и сбор выдачи под кластеризацию

Раздел 3.2 · Рабочие программы

Страница разбирает весь путь настройки. Где лежит поле со списком адресов, в каком формате пишется строка, как связать программу со сборщиком выдачи и сервисом распознавания, сколько адресов брать под 1000, 10 000 и 50 000 запросов, какие ставить паузы и как читать журнал прогона.

1. Что понадобится

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

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

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

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

2. Где в KeyAssort вносится список адресов

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

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

198.51.100.14:8000
198.51.100.27:8000
203.0.113.5:8000:u8134:h2Kq7Rm4
203.0.113.9:8000:u8134:h2Kq7Rm4

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

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

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

3. Связка со сборщиком выдачи и сервисом распознавания

Собрать выдачу можно двумя путями, и адреса нужны обоим.

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

Второй путь: внешний сборщик. Выдача снимается отдельной программой, выгружается в файл и подгружается в KeyAssort как готовые данные. Этот вариант я использую на больших ядрах, потому что внешний сборщик умеет останавливаться, докачивать пропуски и хранить историю по каждому запросу. Список адресов там вносится своим порядком, и удобнее всего взять прокси для Key Collector из того же пакета: пул общий, привязка машины действует на оба инструмента одновременно.

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

Ключ я вписываю до старта и проверяю кнопкой рядом с полем. Она делает пробное обращение к сервису и показывает баланс. Пустой ответ означает опечатку в ключе или сервис, выбранный из списка неверно.

4. Сколько адресов брать под объём запросов

Расчёт строится от одного числа: сколько обращений к поиску безопасно проходит через один адрес за час. Я держу в голове цифру 120, это одно обращение в 30 секунд в среднем. Запас на повторы беру 15 процентов: часть запросов уходит в отказ по таймауту, часть возвращается с проверкой и обходится вторым обращением.

Считается это в два действия. Обращения с запасом делятся на 120, получается сумма адресо-часов, дальше цифра делится на приемлемое время прогона. Для 10 000 запросов: 11 500 разделить на 120 даёт 96 адресо-часов, разделить на 2,5 часа даёт около 40 адресов. Число потоков я держу равным числу адресов, тогда каждый поток работает со своей строкой и интервал между обращениями к одному адресу выдерживается сам собой.

Пул сервиса насчитывает около 12 000 активных адресов, ротация внутри него автоматическая, поэтому набрать 120 строк на крупный прогон труда не составляет. Потоков на обычном пакете доступно 1000, на корпоративном до 3000. При двух привязанных адресах общий лимит делится пополам, и на обычном пакете это по 500 потоков на машину. Для сбора выдачи запас гигантский: программа упрётся в паузы задолго до того, как кончатся потоки.

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

5. Паузы между обращениями и разброс интервала

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

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

Вилка задаётся двумя числами, программа берёт значение внутри диапазона перед каждым обращением. Ширина диапазона важнее середины. Пара 28-32 секунды по разбросу близка к фиксированным 30 и почти ничего не меняет. Пара 15-45 при той же средней даёт живой ряд интервалов. Я ставлю нижнюю границу вдвое меньше верхней и на этом успокаиваюсь.

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

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

6. Разбивка проекта на части

Проект на 50 000 запросов одним куском я не собираю. Причин три, и все они выясняются на практике.

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

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

core-01.txt   5000 запросов   собран
core-02.txt   5000 запросов   собран
core-03.txt   5000 запросов   в работе
...
core-10.txt   5000 запросов   очередь

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

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

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

7. Чтение журнала сбора

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

Смотрю я на четыре вещи.

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

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

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

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

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

8. Проверка после настройки

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

Проверяю по порядку.

Все 20 запросов получили выдачу. Пропуски на таком объёме говорят о проблеме в списке адресов либо в ключе сервиса распознавания.

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

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

curl -x http://203.0.113.5:8000 -U u8134:h2Kq7Rm4 -s https://api.ipify.org

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

Журнал теста без отметок CAPTCHA. Появление проверок уже на 20 запросах означает, что паузу надо расширять до полного прогона. Для тестового объёма мне хватает пары строк из списка, а на боевом прогоне список уходит во внешний сборщик целым набором. Как раскладывать его по потокам, я разбирал на странице про адреса под многопоточный сбор в A-Parser.

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

9. Разбор ошибок

Ниже сообщения, которые встречались мне в KeyAssort чаще прочих, с причиной и порядком действий.

Две ситуации разберу подробнее, потому что диагностируются они плохо.

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

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

Настройки соседних программ справочника разобраны отдельно: маршрутизация приложений в Proxifier пригодится, когда программа полей для посредника не имеет вовсе, запросы к API через Postman закрывают проверку эндпоинтов вручную, загрузка данных в Excel и Power Query помогает свести выгрузки по частям ядра в одну книгу. Для запуска сбора по расписанию на серверной машине смотрите прогон скриптов через PowerShell: там же разобран запуск через планировщик заданий.