Bitrix не тормозит. Тормозит то, как с ним работают
Каждый третий разговор про Bitrix начинается с «он медленный». Я перестал спорить. Вместо этого прошу показать profiler.
Обычно там нет Bitrix.
Там запрос без индекса, кэш который не инвалидируется, ORM который делает N+1 в цикле. Платформа виновата редко. Но именно на неё всё списывают.
Откуда взялся миф
Bitrix — старая платформа. Создана в эпоху, когда PHP 5.3 был нормой, а Redis ещё не был само собой разумеющимся. Часть её внутренней архитектуры несёт этот возраст: события, агенты, связанные между собой таблицы с префиксами b_.
Это правда. Но это не то, что замедляет сайт до 8 секунд загрузки.
Что замедляет — это разработчики, которые работают с Bitrix как с обычным фреймворком. Не читают документацию по кэшированию. Пишут SQL руками прямо в компонентах. Не настраивают PHP-FPM под нагрузку. Ставят сайт на сервер с общим хостингом и удивляются, что 200 конкурентных запросов кладут его на лопатки.
Что показывает profiler у реально медленного сайта
Я открываю реальный profiler — Xdebug или встроенный Bitrix Debug Panel — на «медленном» сайте. Типичная картина:
N+1 в инфоблоках
Разработчик делает выборку товаров через CIBlockElement::GetList() в цикле. Для каждого товара — отдельный запрос за свойствами. 50 товаров на странице = 51 запрос к базе. Это не Bitrix. Это паттерн работы с Bitrix.
Решение: FETCH_DATA_PAGE_SIZE + GetList с SELECT EXTENDED. Один запрос вместо 51. На 28k SKU-каталоге это разница между 4 секундами и 0.3 секунды.
Кэш который не работает
Компонентный кэш Bitrix работает хорошо. Но его легко случайно отключить. Параметр CACHE_TYPE=N в коде компонента, вызов $APPLICATION->ResetAllStaticCache() в неправильном месте, или просто разработчик отключил кэш «на время отладки» и забыл включить обратно.
В profiler-е это выглядит как повторные обращения к базе на каждом запросе для данных, которые меняются раз в день. Статичная витрина → 120 SQL-запросов на страницу.
Включаем кэш → 12 запросов. Остальное из Redis.
Статика без CDN
PHP отдаёт картинки. Nginx есть, но location для статики настроен неправильно или вовсе отсутствует. Сервер тратит PHP-FPM workers на отдачу 40kb JPEG.
При 100 конкурентных пользователях это моментально съедает весь пул workers. Новые запросы ждут. TTFB растёт до 3-4 секунд — сервер занят картинками, а не логикой.
Три реальных источника проблем
Первое — нет кэша на уровне данных. Не компонентного, именно данных. Фильтры строят дерево категорий на каждый запрос — это SQL каждый раз. Redis + немного кода вокруг CIBlockSection::GetList(), и дерево строится один раз, живёт 10 минут, перестраивается по событию.
Второе — не настроен PHP-FPM. pm = dynamic с дефолтными значениями под нагрузку не работает. pm.max_children = 5 при 50 конкурентных пользователях — это гарантированная очередь. Я обычно ставлю pm = static, pm.max_children считаю от доступной памяти: (RAM - OS overhead) / avg_worker_size. На 4GB сервере это 20-25 workers, не 5.
Третье — нет мониторинга slow-запросов. MySQL slow query log отключён. OPcache настроен неправильно: opcache.revalidate_freq=0 в продакшне означает постоянную проверку файловой системы. Это проблемы которые не видно без инструментов, но они накапливаются.
Что сделали за 2 дня и цифры
Последний кейс: интернет-магазин на Bitrix, 3000 товаров, жалобы на медленную работу в пиковые часы.
День 1: включили Bitrix Debug Panel, нашли 3 компонента с отключённым кэшем и один GetList в цикле. Включили кэш, переписали выборку.
День 2: починили Nginx location для статики, перенесли на CDN, пересчитали PHP-FPM workers.
Результат:
- TTFB: 2.1s → 0.4s
- Запросов к БД на страницу каталога: 87 → 9
- Нагрузка в пик: CPU 94% → 31%
Никакого rewrite. Никакой смены платформы. 2 рабочих дня.
Когда Bitrix точно является проблемой
Честно: бывает. Если у вас 500k+ товаров и вы строите real-time фасетный поиск на SQL — Bitrix ORM вам не поможет. Тут нужен Elasticsearch и отдельный индекс. Если у вас 10 000 одновременных пользователей — PHP-монолит упрётся в потолок, и нужно думать про разгрузку через очереди или кэш-слой.
Но это не «Bitrix медленный». Это «мы выросли из сценария использования».
Большинство сайтов до этого не доходят. Их проблема — не архитектурный предел платформы, а неправильная конфигурация и антипаттерны в коде.
Итог
Прежде чем писать «надо переписать» (и подписывать контракт на $40K) — откройте profiler. Посмотрите, сколько запросов к базе делает одна страница. Проверьте, включён ли кэш. Посмотрите на PHP-FPM config.
Скорее всего, там несколько часов работы, а не полгода миграции.