«Битрикс не подходит для высоконагруженных магазинов, он тяжелый и тормозит» – такие фразы слышит почти каждый, кто хоть раз делал большой интернет‑магазин на «1С‑Битрикс». На этом обычно разговор заканчивается советом: «Уходите на чистый фреймворк и собирайте все с нуля».
Но если убрать эмоции и посмотреть на цифры, картина получается куда интереснее.
Большинство реальных магазинов живут в диапазоне от 1 000 до 50 000 товаров, и при нормальной настройке Битрикс эти объемы переваривает спокойно: помогают кэширование, композитный режим, фасетный индекс и продуманная структура инфоблоков. Встречаются и куда более тяжелые случаи – например, интернет‑магазин промышленной электроники с каталогом на 2 миллиона SKU, который работал стабильно именно за счет грамотного кэширования и оптимизации структуры данных.
Что именно протестировали
Провели нагрузочные тесты на типовом интернет‑магазине Битрикс с разными конфигурациями каталога. Смотрели на четыре основные болевые зоны:
- детальная карточка товара;
- список товаров с умным фильтром;
- страница с примененным фильтром;
- поиск.
Нагрузка шла от 10 до 50 запросов в секунду, со сценариями, похожими на поведение реальных пользователей. Параллельно менялись параметры каталога: количество товаров (от 10 000 до 100 000), число SKU, свойств, типов цен, складов, а также включение/отключение фасетного индекса и инфоблоков 2.0.
Важно:
все тесты сначала проводились без кэширования, чтобы увидеть чистую картину, а при включенном кэше время генерации страниц падало до 0,2 секунды и ниже.
Результаты показали несколько неприятных, но полезных закономерностей
- каждый новый тип цены добавляет нагрузку на таблицу с ценами и фасетный индекс, увеличивая время генерации страниц примерно на 5–10%;
- рост числа складов почти не влияет на каталог, но заметно сказывается на корзине и оформлении заказа;
- увеличение количества свойств у SKU резко раздувает фасетный индекс и таблицу свойств, что почти вдвое замедляет страницы списка и фильтрации;
- при объеме таблицы фасетного индекса свыше примерно 10 млн записей MySQL начинает плохо переваривать JOIN’ы, и «умный фильтр» превращается в «очень задумчивый фильтр».
С инфоблоками 2.0 ситуация двоякая: с одной стороны, они уменьшают количество обрабатываемых строк за счет хранения свойств в столбцах отдельной таблицы, с другой – требуют правильной индексации. В тестах переход на инфоблоки 2.0 сначала дал резкий провал: время генерации страниц выросло с ~4 до более чем 10 секунд, пока не был добавлен недостающий индекс по полю привязки SKU к родительскому товару. После этого производительность вернулась в адекватные рамки, а страницы начали открываться быстрее.
Поиск: почему возникают сложности с первым запросом
Отдельная история – встроенный поиск с морфологией. При индексации 50 000 товаров первый запрос без кэша давал 600–1000 SQL‑запросов и до 8 секунд отклика, зато повторные запросы укладывались уже в 1–2 секунды, а с кэшированием – меньше секунды.
Причина проста:
таблицы стемминга и контента разрастаются до десятков миллионов строк, и первый JOIN по ним всегда дается тяжело, зато дальше помогает кэш промежуточных результатов.
Что можно улучшить без тотальной переписки проекта
- убрать из фильтра и индекса те свойства, которые не дают реальной ценности пользователю, но раздувают фасетный индекс;
- ограничить число типов цен и перейти к персональным скидкам и продвинутым схемам ценообразования там, где нужно гибко, а не бесконечно много прайс‑групп;
- заранее продумать количество складов и их роль в логике сайта;
- использовать инфоблоки 2.0 для крупных каталогов, но обязательно проверять наличие индексов на критичных полях;
- индексировать в поиске только необходимые поля и свойства, не превращая таблицы поиска в свалку.
А если каталог действительно огромный?
Есть ситуации, когда все базовые вещи уже сделаны: железо хорошее, MySQL настроен, лицензия бизнес или Enterprise, кэш включен, но каталог на сотни тысяч товаров и миллион SKU все равно душит стандартные компоненты. В таких кейсах универсальность Битрикса становится препятствием: компоненты генерируют слишком много запросов и плохо масштабируются.
Там уже помогают более тяжелые меры:
- вынос свойств и связей в отдельные таблицы или highload-блоки;
- уход фильтрации и поиска во внешние движки вроде ElasticSearch или OpenSearch;
- кастомные схемы кэширования детальных страниц, чтобы не сбрасывать весь кэш при изменении одного товара.
Итог довольно простой: «1С‑Битрикс» сам по себе не приговор для высоконагруженных проектов. Он честно выдерживает десятки тысяч товаров и сотни тысяч SKU при условии, что архитектура, инфоблоки, фасетный индекс, кэш и поиск настроены с головой.
А вот когда каталог улетает в зону миллиона позиций, приходится относиться к Битриксу как к фреймворку: дорабатывать, выносить тяжелые места наружу и осознанно строить архитектуру – вместо того чтобы просто ругаться и бездействовать.
Вашему сайту нужна разработка или доработка? Мы поможем!
