Нагрузочное тестирование сайта 1С-Битрикс

Нагрузочное тестирование сайта 1С-Битрикс

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

Что тестируем

Нагрузочное тестирование Битрикс-сайта включает несколько сценариев:

Нагрузочный тест (Load Test) — постепенное наращивание нагрузки от нуля до ожидаемого пика. Цель: найти точку деградации производительности.

Стресс-тест (Stress Test) — нагрузка выше ожидаемого максимума. Цель: найти точку отказа и проверить, как система восстанавливается.

Spike Test — резкий скачок нагрузки (имитация вирусного поста или рассылки). Цель: проверить поведение при внезапном росте.

Soak Test — продолжительная нагрузка (несколько часов) на рабочем уровне. Цель: найти утечки памяти, накопительные проблемы.

Инструменты

Apache JMeter — многофункциональный, с GUI, поддерживает сценарии с авторизацией, корзиной, AJAX. Подходит для Битрикс, где критичны сессии и динамические страницы.

k6 — современный инструмент, сценарии на JavaScript, удобный для DevOps:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    stages: [
        { duration: '2m', target: 50 },   // наращиваем до 50 пользователей
        { duration: '5m', target: 50 },   // держим 5 минут
        { duration: '2m', target: 200 },  // пик до 200
        { duration: '5m', target: 200 },  // держим пик
        { duration: '2m', target: 0 },    // спад
    ],
    thresholds: {
        http_req_duration: ['p(95)<2000'],  // 95% запросов < 2 с
        http_req_failed: ['rate<0.01'],     // менее 1% ошибок
    },
};

export default function() {
    const res = http.get('https://yourshop.ru/catalog/');
    check(res, { 'status 200': (r) => r.status === 200 });
    sleep(Math.random() * 3 + 1);  // пауза 1–4 с между запросами
}

Яндекс.Танк — российский аналог, хорошо интегрируется с Яндекс.Мониторингом.

Сценарии для Битрикс-магазина

Реалистичный сценарий нагружает не только главную страницу, а типичный путь пользователя:

40% — просмотр страниц каталога (GET /catalog/category/)
20% — поиск (GET /search/?q=товар)
15% — карточки товаров (GET /catalog/product-slug/)
10% — добавление в корзину (POST /cart/add/)
 8% — авторизация и личный кабинет
 7% — оформление заказа

Добавление в корзину через /bitrix/tools/sale_basket.php — это AJAX-запрос с проверкой CSRF-токена. JMeter или k6 должны поддерживать извлечение CSRF из страницы и передачу в POST.

Мониторинг во время теста

Нагрузочный тест без мониторинга сервера — половина работы. Одновременно со стрельбой мониторьте:

PHP-FPM: pm.status_path = /fpm-status — показывает активные/ожидающие воркеры. Если active processes = max_children — PHP-FPM saturated, запросы встают в очередь.

MySQL: SHOW PROCESSLIST и SHOW STATUS — количество подключений, блокировки, slow queries в реальном времени.

Битрикс: панель производительности под нагрузкой покажет, что именно генерирует длинные запросы.

Системные метрики: CPU, RAM, disk I/O, network. Инструменты: htop, iostat -x 1, vmstat 1.

Для автоматического сбора метрик — Prometheus + node_exporter + Grafana. За 2–4 часа настройки даёте команде дашборд с реальными данными.

Типичные узкие места Битрикс под нагрузкой

PHP-FPM исчерпывает воркеры. При pm = dynamic и pm.max_children = 20 — 20 одновременных PHP-запросов. Остальные ждут. Решение: увеличить max_children (с учётом RAM — каждый воркер Битрикс занимает 50–150 МБ) или оптимизировать время ответа PHP.

MySQL: слишком много соединений. Каждый PHP-воркер держит соединение с MySQL. 100 воркеров × 3 сайта = 300 соединений. При max_connections = 151 (default) — ошибки Too many connections. ProxySQL или PgBouncer (аналог для MySQL — ProxySQL) помогают мультиплексировать соединения.

Файловый кеш под нагрузкой. При 200 одновременных пользователях сотни потоков одновременно читают и пишут файлы кеша. Блокировки, inode exhaustion на дешёвых хостингах. Redis как бэкенд кеша устраняет эту проблему.

Сессии. Если сессии в файлах — та же проблема. Redis-сессии под нагрузкой работают стабильнее.

Подготовка к тесту

1. Тестовая среда — по возможности нагружайте staging, идентичный production по конфигурации сервера. Тест на production без согласования с командой — высокий риск.

2. Прогрев кешей — запустите краулер по сайту перед тестом, чтобы кеши были заполнены. Тест с холодными кешами показывает worst case, а не рабочий режим.

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

4. Список URL — возьмите реальные URL из Яндекс.Метрики или Google Analytics. Топ-50 страниц по трафику.

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

Сроки

Нагрузочное тестирование имеет смысл делать после базовой оптимизации: SQL-индексы, кеши, OPcache. Тестировать неоптимизированный сайт — узнать то, что и так понятно.