«Битрикс? Да он же не для больших проектов! Тяжёлый, медленный, с устаревшими инфоблоками и неудобной корзиной — всё надо переписывать!» Слышали такое мнение? Да, оно действительно довольно популярно.

1С-Битрикс часто подвергается критике за недостаточную производительность на крупных и высоконагруженных проектах, особенно если речь идёт о масштабных интернет-магазинах. Когда каталог растёт, а нагрузка увеличивается, совет нередко один: «уходить на фреймворк и строить архитектуру заново».

Но на практике всё не так однозначно. Да, у Битрикса есть свои ограничения, но большинство интернет-магазинов с каталогами до 50 000 товаров прекрасно работают на этой платформе. Ключ к стабильности и высокой скорости — грамотная настройка. От правильно подобранного серверного окружения до оптимизации бизнес-логики.

В арсенале самого Битрикса достаточно инструментов для ускорения работы: фасетный индекс, композитный режим, кэширование на уровне компонентов и продуманная структура инфоблоков. Всё это позволяет добиться отличной производительности без радикальных архитектурных изменений.

А что насчёт по-настоящему тяжёлых кейсов? Они тоже бывают. Например, мы в ИНТЕРВОЛГЕ сопровождали проект с каталогом в 2 миллиона SKU и система работала стабильно. Секрет в том же подходе: глубокая оптимизация, продуманное кэширование и аккуратная организация данных внутри инфоблоков.

В этой статье разберем кейс тестирования производительности Битрикс, уделив особое внимание:

1. Выявлению «узких мест»: определим, на каких операциях (списки товаров, фильтрация, детальная) и при каких объемах данных (количество товаров, SKU, свойств) наблюдается значительное снижение производительности.

2. Количественной оценке: предоставим конкретные метрики времени отклика для разных сценариев нагрузки.

3. Инструментам оптимизации: разберём, какие встроенные механизмы Битрикс (кэширование, фасетный индекс, инфоблоки 2.0) и серверные настройки позволяют существенно повысить отзывчивость системы до применения радикальных мер.

Параметры тестирования

Среда тестирования

Платформа: 1С‑Битрикс: Управление сайтом, версия 25.550.100 (редакция «Бизнес»);

Шаблон: стандартный «Интернет-магазин – Одежда» (два инфоблока: каталог товаров и торговые предложения);

Количество разделов каталога: 12.

Тестирование проводилось на сервере со следующими характеристиками:

• Процессор — 6 ядер по 3,8 ГГц;

• ОЗУ — 10 Гб;

• ПЗУ — SSD, 256 Гб.

В тесте были задействованы четыре ключевые страницы:

• Детальная страница товара;

• Страница списка товаров с умным фильтром;

• Страница примененного умного фильтра;

• Страница поиска.

Какие метрики оценивали:

• Время генерации страницы;

• Суммарное количество запросов на странице;

• Время выполнения запросов.

Также посмотрим, на какой средний RPS можно рассчитывать при разных конфигурациях каталога при идентичных характеристиках сервера.

Нагрузку генерировал Яндекс.Танк в режиме линейного роста: от 10 до 50 RPS в течение 120 секунд (итого 3 600 запросов). Максимальное число инстансов — 20. Для эмуляции пользовательских сценариев использовались страницы каталогов, фильтрации, детальные карточки и страница оформления заказа.

Параметры каталога

Описание полей:

Фасетный индекс — был сгенерирован фасетный индекс или нет;

Тип инфоблоков — какой тип инфоблока каталога и SKU тестировался.

Порядок тестирования

В рамках тестирования проверяли:

1. Какое влияние на производительность оказывает увеличение типов цен, свойств SKU, количество складов (тесты 1–5).

2. Какое влияние на производительность оказывает использование фасетного индекса (тесты 6 и 7).

3. Какое влияние на производительность оказывает использование инфоблоков 2.0 (тесты 6 и 8).

4. На что можно рассчитывать при похожей конфигурации железа и работе с 1 млн SKU (тест 9 в качестве стресс-теста).

Все тесты проводились при выключенном кэшировании. При включенном кэшировании время генерации всех страниц не превышало 0,2 сек.

Результаты тестов

Для начала — сухие цифры с визуализацией.

Количество запросов, которые делает Битрикс

Время генерации страниц

Время исполнения запросов

Интерпретация результатов

Ключевые наблюдения по результатам тестов:

1. Увеличение числа ценовых типов (тест №1 vs №2) приводит к незначительному возрастанию общего числа SQL‑запросов и умеренному росту времени их выполнения на всех проверяемых страницах.

2. Увеличение числа складов (сравнение результатов №2 и №3) не влияет на количество запросов и время их исполнения для всех страниц.

3. Рост количества свойств SKU (сравнение результатов №4 и №5) незначительно повышает количество запросов. При этом значительно увеличивается время их исполнения, но только для страниц списка товаров и страниц с примененным фильтром.

В чем причина роста долгих запросов при увеличении количества свойств SKU? Если посмотреть на запросы, которые выполняются на странице списка товаров, один из самых долгих делает компонент “Битрикс:catalog.smart.filter”. Это запрос для построения динамических фильтров (фасетов) на странице каталога.

Фасетный индекс

В 1С‑Битрикс фасетный индекс (Property Index) оптимизирует «умный фильтр» и вызовы CIBlockElement::GetList с фильтрацией по свойствам. Он хранит для каждого раздела и каждого элемента информацию о доступных значениях свойств и типов цен.

Таблица фасетного индекса содержит следующие поля:

• ID раздела;

• ID элемента;

• FACET_ID — id, которое генерируется на основе того, для чего это значение — свойство или тип цены;

• Значение — хранимое значение.

Использование фасетного индекса при вызове CIBlockElement:GetList включается только, если выполнены все следующие условия:

• Происходит фильтрация свойств;

• Используется логический оператор AND;

• В фильтре есть IBLOCK_ID;

• В фильтре есть фильтрация по разделам SECTION_ID;

• В фильтре установлена фильтрация по активности ACTIVE=”Y”.

Ускорение — это хорошо. Но почему при добавлении небольшого количества свойств мы видим сильную деградацию в скорости выполнения запросов?

Основная проблема кроется в размере таблицы фасетного индекса. Во время теста №4 её объём составлял около 11 миллионов записей, а после добавления новых свойств увеличился до 18 миллионов.

При работе фасетного индекса система выполняет JOIN таблицы элементов с таблицей фасетов, и чем больше становится последняя, тем сильнее это влияет на производительность запросов.

Вывод: если в проекте много разделов, свойств, типов цен или SKU, размер таблицы фасетного индекса быстро растёт, и в определённый момент MySQL перестаёт эффективно обрабатывать такие JOIN-запросы.

На тестовом стенде деградация производительности наблюдалась уже при объёме таблицы фасетов более 10 миллионов записей.

Чтобы оценить примерный размер таблицы фасетного индекса, можно воспользоваться формулой:

Количество записей в таблице фасетов = количество разделов × (количество товаров × количество свойств товаров) + (количество SKU × (количество свойств SKU + количество типов цен))

Для понимания масштаба:

• генерация фасетного индекса для 50 000 товаров с 10 SKU заняла около 50 минут,

• а для 100 000 товаров с тем же количеством SKU — примерно 1,5 часа.

Большое количество свойств

Проблема большого количества записей, которая была выявлена при тестировании с фасетным индексом, на самом деле распространяется и на некоторые другие таблицы, например:

1. При увеличении типов цен будет расти не только таблица фасетов, но и таблица b_catalog_price, которая хранит цены к каждому sku.

2. При увеличении количества складов будет расти таблица b_catalog_store_product, которая хранит остатки по складам.

3. При увеличении количества свойств у sku будет расти таблица b_iblock_element_property, в которой хранятся значения свойств для всех инфоблоков (если это не инфоблоки 2.0).

Проблему с b_catalog_price и b_catalog_store_product можно заметить только при работе с корзиной или на странице оформления заказов. А вот проблема большого количества свойств будет сопровождать на всем конверсионном пути.

Битрикс «из коробки» предлагает решение для хранения большого количества свойств — Инфоблоки 2.0. При переводе инфоблоков в режим 2.0 под каждый инфоблок создается отдельная таблица, и свойства хранятся не как отдельные записи, а как столбцы в новой созданной таблице. Из-за этого количество обрабатываемых строк становится в разы меньше. 

В наших тестах (№7 и №8) видно незначительное ускорение за счет перехода на инфоблоки 2.0. При переводе инфоблока sku на Инфоблоки 2.0 мы обнаружили резкое падение производительности: время генерации детальных и списковых страниц возросло с ~4 сек. до более чем 10 сек. Причиной оказалось отсутствие индекса mysql на столбец со свойством, в котором указана привязка sku к родительскому товару.

После создания индекса командой 

CREATE INDEX idx_prop19_elem 

  ON b_iblock_element_prop_s3 (PROPERTY_19,IBLOCK_ELEMENT_ID);

время генерации страниц значительно уменьшилось (результат теста 8).

Поиск

В 1С-Битрикс реализован собственный поисковый механизм с морфологическим анализом (стеммингом): ключевые слова разбиваются на основы, которые сохраняются в таблицах b_search_content_stem и b_search_stem. В рамках исследования оценивалось исключительно время выполнения поисковых операций, без учёта качества поиска и алгоритмов ранжирования.

Результаты тестирования при индексации 50 000 товаров:

• Первый запрос (без кэша): 600–1000 SQL-запросов, время отклика около 8 секунд.

• Повторный запрос (без кэша): 300–400 запросов, время отклика 1–2 секунды.

• Кэшированная страница: 200–300 запросов, время отклика менее 1 секунды.

Задержка при первом обращении объясняется большим количеством JOIN-операций между крупными таблицами стемминга. Например, таблица b_search_content_stem содержала порядка 29 миллионов записей. Последующие запросы выполняются значительно быстрее за счёт кэширования промежуточных результатов.

Заключение и рекомендации

Важно учитывать, что тестирование проводилось на чистом стенде — без кэшей, оптимизаций и доработок. Такой подход позволяет объективно сравнивать разные конфигурации, но требует осторожности при интерпретации полученных данных. В реальных условиях производительность зависит от архитектуры проекта, качества реализации и конкретных параметров сервера.

Во время тестов сравнивались различные варианты конфигураций каталога, чтобы определить влияние ключевых факторов на скорость работы системы:

• количество типов цен и складов;

• число свойств SKU;

• использование фасетного индекса;

• переход на инфоблоки 2.0.

Ключевые выводы

• Типы цен: каждый новый тип добавляет нагрузку на таблицу b_catalog_price и фасетный индекс, увеличивая время генерации страниц на 5–10%.

• Склады: рост их количества до 50 почти не влияет на страницы каталога, но замедляет корзину и процесс оформления заказа.

• Свойства SKU: увеличение их числа значительно увеличивает объём фасетного индекса и таблицы b_iblock_element_property, что может привести к почти двукратному росту времени выполнения запросов.

• Фасетный индекс: эффективно ускоряет фильтрацию при умеренном количестве свойств, но при превышении 10 млн записей в таблице наблюдается деградация из-за тяжёлых JOIN-операций.

• Инфоблоки 2.0: снижают нагрузку за счёт уменьшения количества строк в таблицах, частично компенсируя минусы фасетного индекса, однако требуют грамотной индексации MySQL-колонок после миграции.

Что можно улучшить без серьёзных доработок компонентов

• Оптимизация фильтрации и свойств. Проведите аудит бизнес-требований: действительно ли все свойства должны участвовать в фильтре? Их избыток напрямую увеличивает объём фасетного индекса.

• Типы цен. Не рекомендуется использовать более 10–20 типов — дальше лучше перейти на кастомные механизмы скидок или индивидуальные расчёты.

• Склады. Минимизируйте их количество ещё на этапе проектирования, чтобы избежать сложных оптимизаций позже.

• Инфоблоки 2.0. Применяйте при каталогах от 50 000 товаров и выше, обязательно индексируя ключевые поля (например, PROPERTY_CML2_LINK). Помните, что в новой модели каждое свойство превращается в отдельный столбец, а MySQL ограничен по их числу — перевод возможен при менее чем 50 свойствах.

• Поиск. Индексируйте только действительно нужные поля и свойства. Избыточная индексация превращает таблицы b_search_content и стемминга в «тормозящие» узкие места.

А если у вас реально большой каталог?

Представим, что у вас:

• 1 млн товаров;

• сотни или тысячи свойств;

• десятки типов цен;

• много складов;

при этом базовая оптимизация уже выполнена: железо обновили, MySQL «подкрутили», лицензия Enterprise куплена, но всё равно всё тормозит.

В этом случае стандартные компоненты Битрикс становятся узким горлышком. Они универсальны, но генерируют много SQL-запросов и плохо масштабируются на очень больших объемах.

Что делали мы в таких ситуациях:

1. Вынос свойств в отдельные таблицы. В одном из проектов (например, marketplace для ЕВРАЗ) каталог содержал тысячи свойств, но реально использовалось лишь несколько сотен. Мы вынесли свойства в отдельные Highload-блоки и перешли на инфоблоки 2.0. Это позволило уменьшить фасетный индекс и повысить производительность фильтрации.

2. Внешние поисковые движки. Перенос фильтрации и поиска в специализированные системы вроде ElasticSearch, OpenSearch или Meilisearch. Да, это требует полной переработки компонентов фильтра, поиска и страницы раздела, но отдача — колоссальная. Вынос тяжелых операций в отдельное приложение разгружает основной сайт и ускоряет отклик в разы.

3. Отдельный кэш для детальных страниц. У Битрикс есть технология тегированного кэша. Она заключается в том, что при обновлении любого элемента инфоблока сбрасывается кэш всех компонентов, которые настроены на данный инфоблок. Из-за этого возникает ситуация, когда вы изменяете один товар в инфоблоке, а кэш детальных страниц сбрасывается у всех остальных товаров. Чтобы решить эту проблему, мы реализовывали кастомный кэш детальных страниц, который сбрасывался только в случае реального обновления элемента.

Битрикс может работать стабильно даже на больших объемах при условии грамотной архитектуры, оптимизации и кастомизации. Стандартных решений будет недостаточно, если проект растет, а требования становятся ближе к enterprise‑уровню.

Мы в ИНТЕРВОЛГЕ любим и умеем работать с такими задачами — приходите, если нужно превратить «тормозной битрикс» в масштабируемый и быстрый интернет-магазин, маркетплейс или другой проект. Заполните форму на нашем сайте, и мы свяжемся с вами для уточнения задачи.