Когда интернет-магазин на Битриксе начинает тормозить под нагрузкой, причина редко одна. В этом кейсе их было три: блокировки базы из-за сессий при параллельных AJAX-запросах, путаница доменов в многосайтовости и AI-боты, которые бесконечно обходили умный фильтр. Сессии я перенёс в Redis, домены развёл в настройках сайтов, агрессивных ботов отсёк на уровне Nginx — и сервер стал отвечать на 40% быстрее.
Что случилось
Три проблемы сразу, и каждая маскировала остальные:
- база данных уходила в глубокие блокировки при обновлении остатков;
- мобильное приложение CRM показывало пустые экраны или ошибки доступа — из-за бага в маршрутизации многосайтовости ядро путало публичный домен магазина с доменом внутреннего портала;
- AI-боты агрессивно сканировали умный фильтр и исчерпывали все воркеры веб-сервера.
Для посетителя всё это выглядело одинаково: «сайт тормозит». Поэтому начинать пришлось не с исправлений, а с полного аудита и разбора, что из этого чем вызвано.
Как понять, почему тормозит Битрикс
Прежде чем что-то чинить, полезно разделить три возможных источника тормозов:
- База. Медленные запросы и блокировки видно в slow query log MySQL и в выводе
SHOW ENGINE INNODB STATUS(раздел о последних взаимных блокировках). Если запросы ждут друг друга — дело не в железе. - PHP и воркеры. Если все процессы PHP-FPM заняты, новые запросы встают в очередь, и даже лёгкие страницы отдаются секундами. Смотрите статус пула и число активных процессов.
- Кто именно ходит. Логи Nginx за час, сгруппированные по User-Agent и по URL, часто сразу показывают, что основную нагрузку дают не люди.
В Битриксе есть ещё и встроенная «Панель производительности» — она грубо, но быстро показывает, упирается ли сервер в базу, в диск или в CPU.
Шаг 1. Сессии в Redis вместо файлов и базы
Блокировки при параллельных AJAX-запросах — классика: когда сессия хранится в файлах или в базе, каждый запрос одного пользователя ждёт, пока предыдущий её отпустит. Умный фильтр, корзина и счётчики шлют запросы параллельно — и выстраиваются в очередь друг за другом.
Перенёс хранение сессий в оперативную память:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"В рамках этого же шага сделал полный аудит и переезд на более быстрое хранилище. Если Redis используется ещё и под кеш, держите сессии в отдельной базе или отдельном экземпляре, иначе очистка кеша заденет пользователей — подробно об этом в кейсе про Redis.
Шаг 2. Развести домены в многосайтовости
Мобильная CRM ломалась из-за того, что ядро путало публичный домен магазина с доменом внутреннего портала. В многосайтовой конфигурации Битрикс определяет текущий сайт по доменному имени, и если у двух сайтов в настройках перепутаны или пересекаются домены, запросы уходят не туда.
Развёл многосайтовость жёстко, прямым SQL:
UPDATE b_lang SET SERVER_NAME='crm.example.com' WHERE LID='s1';
UPDATE b_lang SET SERVER_NAME='example.com' WHERE LID='s2';То же можно поправить в интерфейсе (Настройки → Сайты), но проверьте и поле «Доменное имя» в списке доменов сайта. После правки сбросьте кеш — иначе старые привязки ещё какое-то время поживут.
Шаг 3. AI-боты и умный фильтр
Умный фильтр Битрикса генерирует отдельный URL на каждую комбинацию свойств. Для человека это удобно, для краулера — почти бесконечное пространство страниц, причём каждая без кеша собирается тяжело. Агрессивные AI-краулеры заходят именно туда и занимают все воркеры.
Отсёк самых агрессивных на уровне Nginx — до того, как запрос дойдёт до PHP:
if ($http_user_agent ~* "meta-externalagent|FacebookBot|Bytespider") { return 403; }Список User-Agent здесь — те, кто создавал нагрузку на этом проекте. Перед тем как блокировать, проверьте по своим логам, кто ходит именно к вам: блокировать вслепую можно и полезных ботов.
Шаг 4. Единый кеш для витрины и портала
Последним шагом настроил единый кеш для витрины и портала за счёт статического идентификатора сессии, чтобы одни и те же данные не собирались дважды.
Результат
- Скорость ответа сервера +40%
- Пиковая нагрузка на CPU снижена в 5 раз
- Мобильная CRM полностью восстановлена
- Конверсия в покупку +15%
Как защитить Битрикс от нагрузки краулерами
Что стоит настроить на любом магазине с умным фильтром:
- Robots.txt. Закройте от индексации служебные параметры и бесконечные комбинации фильтра, оставив открытыми только посадочные страницы фильтра, которые вы продвигаете осознанно.
- Блокировка по User-Agent в Nginx для ботов, которые игнорируют robots.txt и не приносят пользы, — по данным ваших логов.
- Ограничение частоты запросов (
limit_reqв Nginx) для URL фильтра: человек не делает десять запросов в секунду, бот делает. - Отдельный мониторинг доли ботов в трафике: AI-краулеров становится больше, и картина меняется каждые несколько месяцев.
FAQ
Почему сайт на Битриксе тормозит при обновлении остатков? Частая причина — блокировки в базе: импорт и пользовательские запросы конкурируют за одни таблицы, а сессии в файлах или в БД заставляют параллельные запросы ждать друг друга. Перенос сессий в Redis и разнос импорта по времени обычно снимают проблему.
Как перенести сессии Битрикса в Redis?
Через настройки PHP (session.save_handler = redis и адрес сервера) или через секцию session в .settings.php. Держите сессии отдельно от кеша, чтобы сброс кеша не разлогинивал пользователей.
Как заблокировать AI-ботов на сайте? Сначала найдите их в логах Nginx по User-Agent, затем блокируйте конкретные имена на уровне веб-сервера и ограничьте частоту запросов к тяжёлым URL вроде умного фильтра.
Почему мобильное приложение CRM не работает на многосайтовом Битриксе? Ядро определяет сайт по домену. Если домены сайтов в настройках пересекаются или перепутаны, запросы приложения попадают не на тот сайт. Проверьте поле SERVER_NAME и список доменов у каждого сайта.