Нагрузочное тестирование сайта 1С-Битрикс
Представьте: интернет-магазин на Битрикс запускает рекламную кампанию, и в первый час приходит 5 000 посетителей. Сайт падает через 10 минут. Типичная ситуация — недостаточное нагрузочное тестирование. Без него каждый рост трафика — рулетка. Мы решаем эту проблему: проводим тесты, выявляем узкие места и гарантируем, что сайт выдержит пик. Средняя стоимость нагрузочного теста — от 100 000 до 200 000 руб., но сэкономленные средства от предотвращения сбоев могут превышать 500 000 руб.
Нагрузочное тестирование (load testing) — это процесс проверки поведения системы под ожидаемой и пиковой нагрузкой (Wikipedia). Для Битрикс это особенно важно из-за особенностей архитектуры, таких как торговый каталог и инфоблоки.
Как подготовить сайт Битрикс к нагрузочному тестированию?
Перед запуском тестов убедитесь, что базовая оптимизация выполнена: SQL-индексы, кэширование и OPcache. Тестировать неоптимизированный сайт — бессмысленно (получите worst case, а не реальную картину). Мы начинаем с аудита конфигурации сервера: версии PHP и MySQL, настройка кэширования на Redis, проверка сессий и файлового кэша. Это гарантирует релевантные результаты.
Какие инструменты выбрать для тестирования Битрикс?
Основные инструменты — Apache JMeter и k6. JMeter многофункционален, с GUI, поддерживает сценарии с авторизацией, корзиной и AJAX. k6 — современный, сценарии на JavaScript, легко встраивается в DevOps. Сравнение: JMeter лучше в сложных сценариях (например, с CSRF-токенами), но k6 проще интегрировать в CI/CD. Для выбора стоит оценить объём тестов и инфраструктуру.
Пример сценария на k6 для интернет-магазина:
import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '2m', target: 50 }, { duration: '5m', target: 50 }, { duration: '2m', target: 200 }, { duration: '5m', target: 200 }, { duration: '2m', target: 0 }, ], thresholds: { http_req_duration: ['p(95)<2000'], http_req_failed: ['rate<0.01'], }, }; export default function() { const res = http.get('https://yourshop.ru/catalog/'); check(res, { 'status 200': (r) => r.status === 200 }); sleep(Math.random() * 3 + 1); } Что тестируем
Полный цикл включает четыре типа тестов:
- Нагрузочный тест (Load Test) — постепенное наращивание до ожидаемого пика для поиска точки деградации.
- Стресс-тест (Stress Test) — нагрузка выше максимума для проверки восстановления.
- Spike Test — резкий скачок (имитация вирусного поста).
- Soak Test — длительная нагрузка для выявления утечек памяти.
Как провести нагрузочное тестирование за 5 шагов
- Составьте сценарий на основе аналитики посещаемости и бизнес-метрик.
- Настройте инструмент (JMeter/k6) и запустите базовый тест.
- Организуйте мониторинг сервера (Prometheus + Grafana).
- Запустите полный цикл тестов — load, stress, spike, soak.
- Анализируйте результаты, оптимизируйте и повторите для подтверждения.
Сценарии для Битрикс-магазина
Реалистичный сценарий нагружает типичный путь пользователя:
40% — просмотр страниц каталога 20% — поиск 15% — карточки товаров 10% — добавление в корзину 8% — авторизация и личный кабинет 7% — оформление заказа Добавление в корзину через /bitrix/tools/sale_basket.php — AJAX с CSRF-токеном. JMeter или k6 должны его извлекать из страницы и передавать в POST.
Мониторинг во время теста
Без мониторинга сервера тест неполноценен. Мы используем Prometheus + node_exporter + Grafana для сбора метрик в реальном времени. Ключевые точки:
- PHP-FPM:
pm.status_path = /fpm-status— если active processes = max_children, воркеры исчерпаны. - MySQL:
SHOW PROCESSLIST— блокировки и slow queries. - Битрикс: панель производительности под нагрузкой.
- Системные метрики: CPU, RAM, disk I/O.
Типичные узкие места Битрикс под нагрузкой
PHP-FPM исчерпывает воркеры. При pm.max_children = 20 — 20 одновременных PHP-запросов. Решение: увеличить max_children с учётом RAM (каждый воркер 50–150 МБ) или оптимизировать время ответа.
MySQL: слишком много соединений. 100 воркеров × 3 сайта = 300 соединений. При max_connections = 151 — ошибки. ProxySQL мультиплексирует соединения.
Файловый кеш под нагрузкой. При 200 пользователях — блокировки. Переход на Redis устраняет проблему.
Сессии в файлах. Аналогичная проблема — Redis-сессии стабильнее.
Что входит в работу
- Составление реалистичных сценариев на основе аналитики
- Настройка инструментов (JMeter/k6) и мониторинга
- Проведение 4 типов тестов
- Анализ результатов с графиками и рекомендациями
- Помощь в оптимизации (кэширование, SQL, конфигурация)
- Финальный повторный тест для подтверждения улучшений
Как интерпретировать результаты?
| Метрика | Хорошо | Допустимо | Плохо |
|---|---|---|---|
| p95 времени ответа | < 1 с | 1–3 с | > 3 с |
| Ошибки (5xx) | 0% | < 0.1% | > 1% |
| CPU сервера | < 50% | 50–80% | > 80% |
| PHP-FPM активные / max | < 60% | 60–85% | > 90% |
Сроки
| Задача | Срок |
|---|---|
| Составление сценариев + настройка инструментов | 1–2 дня |
| Базовый нагрузочный тест + анализ | 1 день |
| Настройка мониторинга | 1 день |
| Итерация: оптимизация + повторный тест | 2–3 дня |
| Полный цикл (4 теста + отчёт) | 1 неделя |
Хотите быть уверены в стабильности сайта? Свяжитесь с нами — мы проведём нагрузочное тестирование и предоставим детальный отчёт с рекомендациями. Закажите тест сейчас и получите скидку 10% на первый проект.