ParserPro

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

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

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

1. Перед началом работы проанализируйте статистику сайта-источника и выберите оптимальное для парсинга время.
   В настоящее время сделать это достаточно просто, так как большинство интересных и стоящих сайтов участвуют во множестве рейтингов, где можно увидеть их посещаемость не только по дням, но и по часам, что особенно важно. Благодаря этому вы можете подобрать время, когда сервер максимально разгружен. Чаще всего это период между 3-7 часами утра.
   Но это не значит, что вы должны в 3 часа утра сидеть перед компом. От вас требуется всего лишь нормально настроить свой компьютер, веб-сервер, поставить на компе будильник (есть такая опция в BIOS Setup) и правильно настроить крон для запуска скриптов.
   А если вы используете сервер хостера, то и того проще - просто поставить скрипт на крон.
   У этого совета есть еще и практически полезная сторона - в ненагруженные часы вы будете получать ответы от сервера-источника на порядок быстрее, чем в “час-пик”, что ускорить парсинг информации и поможет избежать перегрузок на второй стороне.
2. Разбивайте процесс парсинга на максимальное количество независимых процессов.
   Очень часто процесс парсинга является двухуровневым или даже трехуровневым (или еще лучше сказать двухпроходным или трехпроходным), то есть происходит в несколько этапов: сбор ссылок -> парсинг страницы или проход каталога -> сбор ссылок (или прочих параметров) -> парсинг конечных страниц.
   И я в своей работе каждый этап стараюсь реализовать разными скриптами и запускать их в разные промежутки времени, чтобы снизить нагрузку на конечный сервер.
   Это очень удобно и в практическом плане позволяет разделить логику работы скрипта, что несомненно улучшает контроль за процессом и позволяет сделать этапы сбора информации независимыми.
   Конечно же минусом такого разбиения является увеличение времени разработки. Но поверьте, если проект крупный, то затраченное на этой стадии время окупится вам с лихвой.
3. Ставьте паузы между запросами.
   Это важный момент (и парсеры поисковиков знают о чем я говорю :)). И вам не стоит его игнорировать.
   Если ваш парсинг предполагает обработку большого объема информации, то вам стоит добавить между запросами небольшие паузы, которые помогут разгрузить удаленный сервер. В противном случае вы можете забить пул запросов и сайт-источник может плавно умереть. И это поверьте мне это очень плохо, потому что тогда ваши действия могут трактовать как (D)DoS-атаку, а это уже уголовно наказуемо.
   В своей работе работе я, в основном, использую паузы длиной 100-500 мск.
4. Используйте весь возможный инструментарий для снижения объемов передаваемой информации.
   При возможности (если это позволяет сервер-источник) используйте Content-Range в своих HTTP запросах (у curl для этого есть опция CURLOPT_RANGE). Это позволит вам сэкономить как свой траффик, так и траффик сервера-источника.
   К моему удивлению, Яндекс чего-то не захотел обрабатывать данный HTTP запрос.

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

И на последок хочу напомнить, что ваш парсер/граббер в определенный промежуток времени создает нагрузку на порядок больше, чем броузер обычного пользователя. Ведь у парсера не тратится время на рендеринг, парсер не подгружает картинки (если вы ему этого не сказали) и поэтому парсер “листает” страницы сайта-источника на порядок быстрее, чем пользователь. Поэтому не стоит наращивать скорости, потому что вы можете просто “завалить” сервер-источник.

Дополнительные ссылки:

• Спецификация HTTP/1.1