Наш старый клиент обратился с проблемой — сайт начал жутко тормозить и медленно отвечал на запросы, иногда просто падал. Сайт написан на 1C Битрикс, оптимизация кода и сервера казалась очевидным решением. Но реальное узкое место обнаружилось не в плоскости разработки.
Особенности реализации
Для анализа нужны цифры, поэтому вначале мы добавили сайт в нашу систему мониторинга. Она показала серьезную нагрузку на дисковую подсистему при сравнительно нормальной нагрузке на процессор (проект серьёзный, в целом повышенное использование CPU нас не удивило). Проблему с диском мы быстро поправили, так как было очевидно, что базе данных просто не хватает свободной памяти и она начинает эксплуатировать диск.
Но тут произошел неожиданный поворот, после рестарта mysql резко взлетела нагрузка на процессор. Это отлично видно на графике: область 1 — до наших манипуляций с диском, область 2 — полностью отсутствует нагрузка на диск (одна проблема решена) и резко взлетает нагрузка на CPU (новая проблема).
Дальше были почти сутки профилирования и оптимизации, снова профилирование и снова оптимизация кода. Но ничего не помогало — как только мы снимали нагрузку с одной части, резко взлетала нагрузка на другую часть сайта нивелируя эффект от оптимизации. Это казалось замкнутым кругом, при этом трафик и число MySQL процессов говорило о том, что по мере оптимизации кода сайта число запросов увеличивается, что выглядело очень странно.
В Битриксе есть два инструмента для профилирования: инструмент разработчика «Панель производительности» и инструмент менеджера «Скорость сайта». Первый считает реальные обращения к серверу, а второй использует JS код и обрабатывается только при полной загрузке страницы в браузере. И вот тут мы обратили внимание, что «Панель производительности» показывает нам 300-500 обращений за 5 минут, при этом «Скорость сайта» показывает, что реально зафиксированных всего 1000 хитов за 3,5 часа.
Решение пришло само собой: давайте составим список IP с числом запросов и посмотрим, кто же так нагружает сайт? Через пару минут у нас был ТОП IP-адресов за 12 часов (это только часть списка):
Из него видно, что основную нагрузку дает один клиент, и еще с десяток можно заблокировать за излишнюю назойливость. После блокировки этих IP-адресов нагрузка резко упала:
Что это было? Судя по профилю нагрузки — парсеры товаров каталога. Возможно, кто-то анализировал цены, либо собирал контент для своего сайта. Автоматического решения для блокировки таких парсеров, которое бы стоило адекватных денег, не существует. Есть промышленные решения, их стоимость от 7 000 долларов в месяц при годовом контракте.
После написания этих строк прошло около месяц и мы нашли изящное решение. Им оказался набор правил для модуля mod_security. Взяли готовые правила, поправили их под реалии проекта и боты стали успешно отсеиваться. Наблюдаем за сервером уже два месяц и ботов как след простыл. Ни одного «рецидива» за этот период. Страницы больше не тормозят.
Эффект от проведенных работ
Отсеяли ботов и нормализовали нагрузку на сервер. Сайт стал открываться быстрее, чем до старта работ.