Прокси для съёма позиций: расчёт нагрузки, Key Collector и A-Parser

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

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

Что видит поисковая система, когда позиции снимает программа

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

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

Посредник меняет картину в одном месте: обращения расходятся по разным адресам, и счётчик каждого из них остаётся низким. Мы держим пул около 12 000 активных адресов из множества стран, список обновляется в режиме реального времени, доступ к нему открыт клиентам сервиса. Программе достаточно получить этот список и раскладывать по нему запросы, дальше работа идёт своим ходом. Разбор самих кодов и того, что делать при их появлении, собран в материале про ошибку 403 при работе через прокси.

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

Расчёт нагрузки: запросы, глубина и окно съёма

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

Формула короткая. Число обращений за съём равно числу запросов, умноженному на глубину. Требуемая скорость равна числу обращений, делённому на длину окна в секундах. Пример: 5 000 запросов при глубине в 3 страницы дают 15 000 обращений, и если окно составляет шесть часов, скорость выходит около 0,7 обращения в секунду.

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

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

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

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

При отклике 1,4 секунды и паузе 5 секунд цикл занимает 6,4 секунды, и один поток выдаёт около 0,16 обращения в секунду. Делим требуемую скорость на эту величину и получаем число потоков. Расчёт занимает полминуты и снимает главный источник ошибок: потоки, взятые круглым числом наугад.

Цифры в правой колонке объясняют, почему для съёма позиций хватает стандартного пакета. Даже ядро на 30 000 запросов с глубиной в пять страниц укладывается в шестьдесят потоков, а стандартные пакеты дают до 1000 потоков. Корпоративный вариант с лимитом до 3000 потоков берут агентства, которые ведут десятки проектов одновременно и гоняют их с нескольких машин параллельно.

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

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

Настройка Key Collector и A-Parser под работу с пулом

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

# формат для машины с привязанным адресом
185.24.87.14:8000
185.24.87.15:8000

# формат с парой логина и пароля
185.24.87.14:8000:user5521:pf39kd
185.24.87.15:8000:user5521:pf39kd

Key Collector

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

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

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

A-Parser

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

# источник списка адресов
type: link
url: https://<адрес выдачи из кабинета>
format: ip:port:login:pass
update: 600

# параметры задания съёма
threads: 12
proxyretries: 3
requestdelay: 5000
requestdelayrandomize: 40
timeout: 20

Поле requestdelayrandomize даёт разброс паузы: при базовых пяти секундах и разбросе в сорок процентов интервал гуляет от трёх до семи секунд. Такой разброс убирает главный признак программы, ровный такт обращений. Про типовые настройки прогонов написано на странице про прогоны в A-Parser через пул адресов.

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

curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
  -x http://user5521:[email protected]:8000 \
  "https://example.org/search?q=test&start=0"

Пауза между обращениями и то, чем она управляет

Пауза выставляется на поток, поэтому суммарный темп считается умножением. Двенадцать потоков с паузой в 5 секунд дают около двух обращений в секунду по заданию целиком. Администратор, который поднял потоки до сорока и оставил ту же паузу, получает почти восемь обращений в секунду и удивляется появлению страниц подтверждения.

Разброс паузы важнее её длины. Ровный интервал читается по логам сервера мгновенно, случайный разброс в интервале от трёх до семи секунд выглядит совершенно обычно. В Key Collector разброс задаётся диапазоном, в A-Parser полем requestdelayrandomize, в собственном скрипте одной строкой со случайным числом.

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

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

Съём по расписанию: как ставить прогоны и не собирать отказы

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

# обновление списка адресов и запуск съёма в 02:40 по будням
40 2 * * 1-5 curl -s "https://<адрес выдачи из кабинета>" -o /opt/rank/proxies.txt \
  && /opt/rank/run-positions.sh --project main --depth 3 --threads 12

# проект помельче стартует на сорок минут позже, чтобы окна не накладывались
20 3 * * 1-5 /opt/rank/run-positions.sh --project shop --depth 1 --threads 6

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

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

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

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

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

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

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

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

Разные языки интерфейса: как проверять выдачу корректно

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

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

# английский интерфейс
curl -s -x http://user5521:[email protected]:8000 \
  -H "Accept-Language: en-US,en;q=0.9" \
  "https://example.org/search?q=proxy+setup&hl=en"

# русский интерфейс, тот же запрос
curl -s -x http://user5521:[email protected]:8000 \
  -H "Accept-Language: ru-RU,ru;q=0.9" \
  "https://example.org/search?q=настройка+прокси&hl=ru"

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

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

Хранение результатов и сверка между съёмами

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

CREATE TABLE positions (
  snap_date   DATE    NOT NULL,
  query       TEXT    NOT NULL,
  ui_lang     TEXT    NOT NULL,
  page_url    TEXT,
  pos         INTEGER,
  serp_page   INTEGER,
  ok          INTEGER NOT NULL DEFAULT 1,
  PRIMARY KEY (snap_date, query, ui_lang)
);

-- движение позиций между двумя последними съёмами
SELECT a.query, b.pos AS was, a.pos AS now, b.pos - a.pos AS delta
FROM positions a
JOIN positions b
  ON a.query = b.query AND a.ui_lang = b.ui_lang
WHERE a.snap_date = '<новая дата>'
  AND b.snap_date = '<предыдущая дата>'
  AND a.ok = 1 AND b.ok = 1
ORDER BY delta;

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

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

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

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

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

Подойдут ли прокси под съём позиций по моей семантике?

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

Есть ли ограничения по числу потоков?

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

Можно ли отобрать адреса под конкретную страну?

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

Как часто обновляется список адресов?

Список обновляется в режиме реального времени, забрать его можно ссылкой или файлом в двух форматах, IP:PORT и IP:PORT:LOGIN:PASS. Для съёма по расписанию удобнее ссылка: скрипт перечитывает её перед каждым стартом и работает с актуальным составом пула. Сам пакет после оплаты включается примерно за 5 минут, и оформить доступ к пулу адресов IPv4 можно там же, в кабинете.

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