High-load на Битрикс — не миф, но и не «включил кеш и забыл». Когда каталог насчитывает сотни тысяч SKU, а пиковый трафик приходит с рекламы или распродажи, узкие места проявляются в БД, PHP и интеграциях. Начинать нужно с измерений, а не с догадок.

Первый шаг — нагрузочное тестирование на копии продакшена: сценарии просмотра каталога, поиска, корзины и оформления заказа. Фиксируем TTFB, время ответа API 1С и процент ошибок. Без цифр оптимизация превращается в бесконечную смену настроек.

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

Композитный кеш и CDN — база для публичной части. Статика и типовые страницы отдаются с edge, динамика — через умное кеширование блоков. Для каталога критичны индексы в БД, отказ от N+1 в компонентах и вынос тяжёлых фильтров в Elasticsearch или встроенный поиск с правильной настройкой.

Первые шаги к масштабированию Битрикс-проекта

Сессии и корзина на high-load часто выносят в Redis. Очереди для обмена с 1С — через агенты или message broker, чтобы пик заказов не положил учётную систему. Мониторинг: APM, логи медленных запросов, алерты при росте очереди.

  • Нагрузочные тесты на реальных сценариях пользователей
  • Композит, CDN и оптимизация тяжёлых компонентов каталога
  • Индексы БД, профилирование запросов, поиск через ES при необходимости
  • Redis для сессий и кеша, очереди для обмена с 1С
  • Мониторинг, алерты и план роста инфраструктуры

Масштабирование — горизонтальное: несколько app-серверов за балансировщиком, отдельный сервер БД, выделенный кеш. На этапе ТЗ закладываем целевые RPS и SLA — тогда архитектура растёт вместе с бизнесом, а не ломается в первый чёрный пятницу.

Теги: 1С-Битрикс High-Load Производительность