Скорость и принцип работы парсеров
Перед тем как говорить о скорости нужно понимать принцип работы парсера в целом. Ведь если знаешь, как работает программа, то можно понять, собственно, что влияет и на скорость этой программы.
Принцип довольно прост: парсер делает запрос на сервер (любой сайт всегда находится на каком-то сервере), получает данные и предоставляет результат. На практике достаточно использование Post и Get запросов к серверу.
Как видно на рисунке, всё достаточно просто. Исходя из этого можно уже понять, что влияет на скорость парсинга. Также более детальный алгоритм, порядка обработки запроса от его чтения из файла(или текста) до сохранения конечного результата в файл, описан тут: a-parser/wiki/query-results-relation/
Влияние юзер-агента и отличие от браузера
Заголовок запроса User-Agent - это характеристическая строка, которая позволяет серверам и одно ранговым узлам сети идентифицировать приложение, операционную систему, поставщика и/или версию запрашивающего пользовательского агента.
Если коротко, то это один из отпечатков вашего запроса. Юзер-агент используют чтобы показать серверу какой используется браузер.
Но ведь у нас парсинг, причем тут браузер? Дело в том, что на сайтах часто делают ограничения по этому самому юзер-агенту, ведь это очень подозрительно если на сервер поступает запрос без юзер-агента, ведь запрос браузера всегда имеет в себе юзер-агента.
Бывает, что А-Парсер не находит что-то, хотя если выполнить запрос в браузере, то всё прекрасно видно. Почему так?
А-Парсер получает код страницы, как и браузер, но не выполняет его, в отличии от браузера, который обрабатывает скрипты и показывает уже результат этих самых скриптов.
Скорость парсинга
Нам очень часто задают вопросы по скорости парсинга, почему скорость упала, как увеличить скорость, почему при парсинге в 2000 потоков скорость меньше чем при парсинге в 500 потоков и другие подобные вопросы.
Перво-наперво нужно понимать, что скорость не зависит только от количества потоков и прокси. Потому что перегруз потоков, это всегда падение производительности. Да потоки и прокси очень важны, но нужно понимать, что есть и другие факторы которые влияют на парсинг.
Часто, когда нас спрашивают, что влияет на скорость парсинга, то мы отвечаем что-то подобное: «Смотря какой сайт парсить, какие данные, нужны ли для этого прокси и т.д. Скорость зависит от конкретной страницы, ее нужно анализировать, искать нужные запросы и их использовать для парсинга. Тут наверняка нельзя ответить без привязки к задаче. Также, от необходимой логики для поиска нужных данных, от железа и канала интернета, от кол-ва потоков, от качества прокси...»
Скорость зависит от железа. Видно, как много всего влияет на скорость. И можно заметить, что прокси в самом конце всего. Да, если парсить до 100 потоков, то обычно проблем нет, но что если нужно 2000 или больше как быть? Разберём эту ситуацию.
Возьмём для тестов такой пресет, добавим задание и посмотрим результат.
Вот мы парсим Google в 100 потоков.
Вот мы парсим Google в 1000 потоков.
Что же у нас получается, мы увеличили число потоков, но скорость у нас не то что выросла, она просто упала в примерно 1.5 раз. Почему же? Ответ найти очень просто, если посмотреть загрузку ЦП во время выполнения задания.
Когда парсим Google в 100 потоков. Мониторинг ЦП.
Когда парсим Google в 1000 потоков. Мониторинг ЦП.
Видно, что, когда мы парсили в 1000 потоков, ЦП был просто перегружен потоками и таким образом производительность парсера просто упала, а значит и скорость парсинга была снижена.
Скорость зависит от неудачных запросов. Хорошо, допустим мы решили вопрос с производительностью ЦП, и мы хотим больше скорости. Смотрим, да, у нас слишком много неудачных запросов. Как же так, неужели А-Парсер плохо работает?
На самом деле, нет, неудачные запросы хоть и напрямую влияют на показатель скорости, но это не значит, что А-Парсер плохо работает. Есть два самых действующих метода снижения показателя неудачных запросов: добавить больше попыток или добавить сервис распознавания капчи. В любом случае эффективность парсинга вырастет, так как неудачные запросы сократятся к минимуму. Скорость может отличаться, так как будет тратиться время на повторный запрос с другим прокси, если прокси в бане или попалась капча (если нет распознавания капчи). Также нужно понимать, что процесс распознавания капчи не моментальный и требует некоторого времени. Так как А-Парсер не разгадывает капчу, а использует специальные сервисы, которым отправляет капчу и получает решение.
Проверим на тестовом пресете, взяв тестовый пресет и второй такой же только изменив одну опцию:
Request retries = 10
Парсим Google в 100 потоков, Request retries = 100.
Парсим Google в 100 потоков, Request retries = 1.
Вау! Скорость выросла, но… также и показатель неудачных запросов вырос. Как это случилось? Если включить логи задания, мы увидим, что часть запросов не выполнилась успешно по самым разным причинам, но запрос был завершен, а значит и учтён в показателе общей скорости. Для этого и нужна опция Request retries, чтобы парсер мог быстро повторить запрос, но уже с другой прокси.
Скорость зависит от конкретной страницы. Почему? Всё просто, страница имеет объем и этот объем нужно получить, а значит, чем больше объем страницы, тем больше времени на получение. Из этого вытекает и следующие, что скорость парсинга зависит еще и от скорости вашего интернета. Также следует добавить, что большие объемы потоков нагружают не только ЦП, а и вашу сеть, а именно роутер.
Скорость зависит от парсера. Почему? Дело в логике работы каждого отдельного парсера, хоть и идея парсинга одинакова, но алгоритмы в каждом отдельном парсере отличаются. Банально сравнить представленный выше тестовый пресет и любой другой пресет из каталога. Первый намного проще чем второй, в нем нет никакой дополнительной логики, фильтрации, регулярных выражений и других вещей которые делают парсер более сложным.
Сравним пресеты, взяв тестовый пресет и второй такой же только изменив одну опцию:
Pages count = 2
Теперь парсер должен делать в два раза больше запросов. Для первой страницы выдачи и для второй. Посмотрим результаты.
Парсим Google в 100 потоков, Pages count = 1.
Парсим Google в 100 потоков, Pages count = 2.
Видно насколько упала скорость, ровно в два раза. Вот так влияет сложность пресета.
