Сканируем большие сайты через Screaming Frog SEO Spider

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

Главные заблуждения:

- Лягушка регулярно падает;

- Сканировать можно до 500 тысяч;

- Это крайне долго;

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

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

Задача - просканировать сайт с Х миллионами страниц и не попасть на передачу "Сдохни или умри". Конечно, можно оплатить тариф у JetOctopus, но проводя аналитику не только своих сайтов, но и конкурентов, разорение неминуемо.

Конфигурация сервера

Чтобы парсинг не мешал основной работе я использую сервер, собранный из китайских запчастей. Моя конфигурация не самая удачная (много жрёт электричества, сильно греется), но с задачей краулинга справляется отлично - два 8 ядерных процессора E5-2689, 1080 (другой не было), 48 GB RAM (REG ECC), ну и Windows Server на борту, поскольку бесплатная на полгода и не перегружена всякой шелухой от майкрософта. Нужен ли такой монстр? Разумеется нет, для объективности, установил в BIOS 2 ядра по 3.5 ггц и запустил те же самые настройки. Скорость парсинга не упала, но загрузка процессоров была 80-90%. Краулить реально без выполнения других задач.

Настройки программы

Теперь к основному, настройки программы. Первое и самое главное:

Configuration - Systeam - Storage Mode - Устанавливаем DataBase.

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

Вторым шагом зададим размер оперативной памяти (Configuration - Systeam - Memory Allocation). Разработчики рекомендуют от 4 гб для парсинга 2 млн страниц и 8 гб для 5 и более. У меня стоит 24, потому что могу. На самом деле, выставлять 16-32-48 гб памяти здесь нет необходимости, она нужна только для работы каждого из потоков.

Сканирование большого числа страниц = большой размер проекта. Отключаем лишнее. Залетаем в Configuration - Spider. Здесь оставляем парсинг только внутренних ссылок (если планируете искать битые внешние ссылки и прочее, разумеется включаем):

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

http.*\.jpg
http.*\.JPG
http.*\.jpeg
http.*\.JPEG
http.*\.png
http.*\.PNG
http.*\.gif
http.*\.pdf
http.*\.PDF

Отлично, теперь изображения точно не будут собираться.

Напоследок, Configuration - Speed. Здесь всё крайне индивидуально и зависит от:

- Возможностей сервера с которого идёт парсинг;

- Возможностей сервера который парсим;

- От интернет канал;

Я ставлю от 7 до 10 потоков (10-30 урлов в секунду), этого хватает для комфортной работы всех сторон.

Подводные

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

К цифрам

Всё это было бы бессмысленными теориями, если бы не было обкатано в бою.

Парсинг любого проекта я выполняю в два этапа:

- Первичный, понять очевидно проблемные разделы с мусорными страницами. Собирается 5-10% от будущего объема сайта и на основе данных структуры (Site Structure в сайдбаре) оцениваем что за разделы и для чего они нужны по количеству страниц в них;

- Вторичный, с отключенными проблемными разделами (через Exclude), чтобы найти более мелкие ошибки в рамках всего сайта.

Итак, на последнем проекте изначально было несколько проблемных разделов с 17-ю(!) уровнями вложенности. Размер проекта раздувался в космос, каждый следующий миллион страниц весил дополнительные 100 гб места на диске. Скорость через 1.5 млн страниц упала с 20-30 урлов в секунду до 2-3. Всего урлов в ожидании к тому моменту было 5 млн и это явно не предел.

Вторым этапом, исключив мусорные разделы, запустил парсинг повторно. В итоге, на сайте осталось 2 млн страниц и в 10 потоков (20-30 урлов в секунду, да там хороший сервер) он парсился ровно сутки. Удивился сам, но совпало с теоретическими расчётами: 2 000 000 / 20 (урлов в сек) / 3600 (часов) = 28 часов. При этом размер базы для всего проекта составил порядка 50 гб, что в 4 раза меньше прошлого парсинга для того же количества страниц.

Выводы

Краулинг значительного объёма страниц реален и не так страшен, как о нём думают. Достаточно 4-х ядерной машины с 8-16 гб оперативной памяти и не сильно большого SSD. Сама лягушка такие объемы тянет и не падает.

При любом сканировании после первых 10-15%, оцените структуру сайта и посмотрите, какие разделы могут генерировать много лишних страниц. Исключите их из парсинга и перезапускайте сканирование уже до финала. Успехов!