Нагрузочное тестирование интернет-магазина 1С-Битрикс
Типичная ситуация: магазин работает стабильно при 30 посетителях онлайн, а при 300 — страницы каталога открываются по 8 секунд, оформление заказа падает с таймаутом, в логах nginx — 502 Bad Gateway. Владелец узнаёт об этом в первый день распродажи. Потенциальная экономия от своевременного тестирования может достигать нескольких миллионов рублей. Мы помогаем выявить узкие места до того, как они станут критическими.
Почему нагрузочное тестирование необходимо перед распродажами?
Без тестирования вы рискуете потерять до 70% выручки в день акции. Трафик может превысить текущие мощности в 10–20 раз, и без подготовленного плана масштабирования магазин ляжет. Нагрузочное тестирование даёт ответы: сколько запросов в секунду держит текущая конфигурация, где узкое место (БД, PHP-FPM, внешние API) и какой запас прочности нужно заложить. Своевременное выявление узких мест позволяет избежать потери выручки, которая может исчисляться миллионами рублей.
Инструменты генерации нагрузки
k6 — выбор номер один для большинства проектов. Сценарии на JavaScript, минимальное потребление ресурсов (одна машина выдаёт 5000+ RPS), нативная интеграция с Grafana для визуализации в реальном времени. Хранится в репозитории, запускается в CI/CD. Пример сценария для каталога Битрикс:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 }, // ramp-up
{ duration: '5m', target: 100 }, // plateau
{ duration: '2m', target: 300 }, // stress
{ duration: '5m', target: 300 }, // hold
{ duration: '2m', target: 0 }, // ramp-down
],
};
export default function () {
// Главная → раздел → фильтрация → карточка товара
let res = http.get('https://shop.example.com/catalog/electronics/');
check(res, { 'catalog 200': (r) => r.status === 200 });
res = http.get('https://shop.example.com/catalog/electronics/?filter_brand=samsung&filter_price_from=10000');
check(res, { 'filter 200': (r) => r.status === 200 });
res = http.get('https://shop.example.com/catalog/electronics/samsung-galaxy-s24/');
check(res, { 'product 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 1); // пауза 1-4 сек, имитация реального пользователя
}
Apache JMeter — проверенный стандарт, требует Java и потребляет больше RAM, поэтому для высоких нагрузок может понадобиться несколько инстансов. GUI для создания сценариев, запись через прокси, поддержка cookies и авторизации. Подходит для команд, привыкших к визуальным инструментам.
Gatling — Scala DSL, неблокирующий I/O, детальные HTML-отчёты с перцентилями. Эффективнее JMeter по ресурсам, но порог входа выше.
| Инструмент | Язык | RAM на 1000 VU | Отчёты | CI/CD |
|---|---|---|---|---|
| k6 | JavaScript | ~200 МБ | Grafana / JSON | Нативная |
| JMeter | GUI / XML | ~2 ГБ | Плагины (JTL) | Через CLI |
| Gatling | Scala DSL | ~500 МБ | HTML встроенные | Нативная |
Четыре сценария, которые нужно тестировать
Нагрузочный тест без реалистичных сценариев — бессмысленная генерация трафика на главную страницу. Для Битрикс-магазина критичны:
- Просмотр каталога (60-70% трафика): главная → раздел → фильтрация → карточка товара. Фильтрация — самое тяжёлое место. Компонент bitrix:catalog.smart.filter генерирует 30-50 SQL-запросов на один хит.
- Поиск (10-15% трафика): модуль search использует FULLTEXT-индекс, который деградирует нелинейно на 100 000+ товаров.
- Корзина (5-10% трафика): каждое действие (добавление, купон) вызывает пересчёт скидок через RuntimeCache, занимая 200-500 мс.
- Оформление заказа (2-5% трафика): самый критичный сценарий — 50-100 SQL-запросов и 1-3 HTTP-запроса к внешним сервисам.
Как выявить узкие места Битрикс?
Нагрузочный тест показывает, что тормозит. Профилирование — почему.
Xhprof / Tideways — расширения PHP для профилирования с оверхедом 5-15%. Включается на продакшене под нагрузкой, генерирует callgraph. Типичная находка: CIBlockElement::GetList() вызывается 47 раз на одной странице каталога.
Slow query log — обязателен во время теста. Для MySQL: slow_query_log = 1, long_query_time = 0.3. Типичная находка — запрос фильтрации с пятью JOIN по таблицам свойств, просматривающий 2.3 миллиона строк за 4.2 секунды.
Типичные узкие места Битрикс
- Компоненты без кеша: bitrix:catalog.section с CACHE_TIME = 0 — каждый хит генерирует запросы к инфоблоку и ценам. Решение — тегированный кеш (CACHE_TIME = 3600).
- Множественные свойства инфоблоков: каждое свойство хранится отдельной строкой, фильтрация по трём свойствам даёт три дополнительных JOIN. Фасетный индекс решает проблему.
- OPcache: без него Битрикс компилирует тысячи PHP-файлов при каждом запросе. Настройте opcache.memory_consumption = 256, max_accelerated_files = 20000.
- Сессии в файлах: при 500+ одновременных пользователях ext4 тормозит. Используйте Redis: session.save_handler = redis.
- Агенты на хитах: define('BX_CRONTAB_SUPPORT', true) и перенос агентов на cron.
Ключевые метрики
- RPS — запросов в секунду без деградации (для среднего магазина 100-300).
- TTFB — до 200 мс для закешированных страниц, до 500 мс для динамических.
- P95 response time — время для 95% запросов. Если P95 > 4 секунд — каждый двадцатый посетитель ждёт долго.
- Error rate — процент 5xx и таймаутов. При превышении пропускной способности растёт резко.
Что делать с результатами?
| Проблема | Метрика | Решение |
|---|---|---|
| TTFB > 1 с на каталоге | P95 | Компонентный кеш + композитный кеш |
| 502 при 200+ RPS | Error rate | Увеличение pm.max_children, тюнинг max_connections |
| Slow query > 2 с | Slow query log | Фасетный индекс, составные индексы, Elasticsearch |
| OOM при 300 пользователях | Memory usage | OPcache, memory_limit, отключение модулей |
| Таймаут при checkout | TTFB | Асинхронная обработка событий, кеш доставки |
Когда тестировать
Нагрузочное тестирование — не разовая процедура. Запускайте перед распродажами (Чёрная пятница, 11.11), после миграции сервера, после обновления ядра Битрикс, после массового импорта товаров. k6 в CI/CD позволяет запускать базовый smoke-тест при каждом деплое.
Как провести нагрузочное тестирование в 5 шагов
- Сбор профиля нагрузки: типовые сценарии, частота запросов, пиковый трафик.
- Настройка окружения: staging с включённым мониторингом и профилированием.
- Разработка сценариев: скрипты на k6, имитирующие каталог, поиск, оформление заказа.
- Запуск и мониторинг: постепенное наращивание нагрузки, фиксация метрик RPS, TTFB, P95, error rate.
- Анализ и оптимизация: изучение slow query log, профайлера, внесение изменений и повторный тест.
Что входит в работу
Мы предоставляем полный цикл нагрузочного тестирования под ключ:
- Анализ архитектуры и профиля нагрузки вашего магазина.
- Разработка реалистичных сценариев (каталог, поиск, корзина, checkout).
- Запуск тестов на staging или production (с согласованием).
- Сбор метрик и профилирование (xhprof, slow query, OPcache).
- Детальный отчёт с метриками, узкими местами и рекомендациями.
- План первоочередных оптимизаций с оценкой трудозатрат.
- Консультация инженера по результатам.
Свяжитесь с нами для консультации — мы оценим ваш проект за 1-2 дня. Закажите тестирование перед распродажами, чтобы избежать потери выручки.