Краулер соцсети уронил CPU в три раза через фасетные фильтры
На двухъядерном сервере интернет-магазина за 15 минут load подскочил с 0.4 до 12.7 — сайт начал тормозить. Виноват оказался не наплыв покупателей, а один краулер, который методично обходил URL фасетных фильтров каталога. Разбираем, как отличили бота от нагрузки и погасили её за две минуты.
Симптом
Интернет-магазин на 1С-Битрикс, 2 vCPU. Алерт мониторинга: cpu_load за 15 минут вырос с 0.4 до 12.7 — то есть очередь задач в шесть раз превышала число ядер. Сайт ощутимо тормозил, Apache упирался в воркеры.
Разведка
Первый вопрос при скачке нагрузки — это реальные покупатели или бот. Разобрали access-логи по User-Agent и URL. Картина однозначная: краулер meta-externalagent (обходчик соцсети) слал 319 запросов в минуту по адресам вида /catalog/.../filter/brand-XXX/apply/.
Причина
Каждый такой URL — это не отдача статики, а полноценный расчёт фасетного фильтра: тяжёлый PHP плюс сложный MySQL-join по свойствам. Пользователи так каталог не листают — а бот методично перебирал комбинации фильтров, и каждый его запрос стоил серверу дорого. Двух ядер на такой перебор не хватало.
Что сделали
Точечно, не задев живой трафик и превью-карточки товаров для соцсетей:
- в nginx — условный
return 429дляmeta-externalagent|facebookexternalhitтолько на путях^/catalog/.+/(filter|apply); - в
robots.txt—Disallow: /*/filter/и/*/apply/, чтобы добросовестные краулеры вообще не заходили в комбинаторику фильтров.
Важно, что мы не банили бота целиком — страницы товаров, по которым строятся превью ссылок в соцсетях, остались доступны.
Результат
load упал с 12.30 до 4.15 за две минуты, число Apache-воркеров снизилось с 13 до 9. Сайт вернулся к нормальной скорости. Мораль простая: под «сервер тормозит» часто прячется не рост бизнеса, а один невоспитанный краулер в тяжёлой части каталога — и лечится это не апгрейдом железа, а десятком строк в nginx.
Имя клиента не раскрываем по NDA. Цифры и подход — реальные.