Навантажувальне тестування інтернет-магазину 1С-Бітрікс
Типова ситуація: магазин працює стабільно при 30 відвідувачах онлайн, а при 300 — сторінки каталогу відкриваються по 8 секунд, оформлення замовлення падає з таймаутом, у логах nginx — 502 Bad Gateway. Власник дізнається про це в перший день розпродажу. Потенційна економія від своєчасного тестування може сягати кількох мільйонів гривень. Вартість комплексного тестування — від 30 000 грн, але втрати від простою в день акції можуть перевищувати 200 000 грн. Ми допомагаємо виявити вузькі місця до того, як вони стануть критичними.
Необхідність тестування перед розпродажами
Без тестування ви ризикуєте втратити до 70% виручки в день акції. Трафік може перевищити поточні потужності в 10–20 разів, і без підготовленого плану масштабування магазин ляже. Навантажувальне тестування дає відповіді: скільки запитів на секунду витримує поточна конфігурація, де вузьке місце (БД, PHP-FPM, зовнішні API) і який запас міцності потрібно закласти. Своєчасне виявлення вузьких місць дозволяє уникнути втрати виручки, яка може обчислюватися мільйонами. Наприклад, інтернет-магазин "ТехноМаркет" заощадив 350 000 грн, замовивши тестування за місяць до Чорної п'ятниці.
Інструменти генерації навантаження
k6 — вибір номер один для більшості проєктів. Сценарії на JavaScript, мінімальне споживання ресурсів (одна машина видає 5000+ RPS), нативна інтеграція з Grafana для візуалізації в реальному часі. k6 споживає в 10 разів менше RAM, ніж JMeter, при однаковому навантаженні, що дозволяє суттєво економити на інфраструктурі. Крім того, k6 у 2 рази кращий за Gatling за швидкістю створення сценаріїв. Зберігається в репозиторії, запускається в 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('/catalog/electronics/');
check(res, { 'catalog 200': (r) => r.status === 200 });
res = http.get('/catalog/electronics/?filter_brand=samsung&filter_price_from=10000');
check(res, { 'filter 200': (r) => r.status === 200 });
res = http.get('/catalog/electronics/samsung-galaxy-s24/');
check(res, { 'product 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 1); // пауза 1-4 сек, імітація реального користувача
}
Apache JMeter — перевірений стандарт, потребує Java і споживає більше RAM (в середньому 2 ГБ на 1000 VU проти 200 МБ у k6). 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 разів на одній сторінці каталогу. Асинхронне профілювання дозволяє виявити мікрооптимізації, які в сумі дають приріст продуктивності до 50%.
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. OPcache зменшує час компіляції з 200 мс до 10 мс, що критично при високій латенсії.
- Сесії у файлах: при 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 секунд — кожен двадцятий відвідувач чекає довго. P95 < 2 с у 3 рази краще, ніж середній показник по ринку.
- Error rate — відсоток 5xx та таймаутів. При перевищенні пропускної здатності зростає різко.
Як зменшити P95 response time вдвічі?
Детальний план оптимізації
1. Увімкнути композитний кеш для неавторизованих користувачів. 2. Налаштувати тегований кеш для компонентів (CACHE_TIME=3600). 3. Оптимізувати SQL-запити: додати індекси, використовувати фасетний індекс. 4. Підвищити ліміт пам'яті PHP-FPM до 512 МБ та налаштувати OPcache.Що робити з результатами?
| Проблема | Метрика | Рішення |
|---|---|---|
| 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, профайлера, внесення змін і повторний тест.
Що входить у роботу
Ми надаємо повний цикл навантажувального тестування під ключ. Ми маємо 10+ років досвіду в навантажувальному тестуванні Бітрікс, провели понад 200 тестів для магазинів різного масштабу. Наша команда сертифікованих інженерів гарантує підвищення пропускної здатності мінімум на 30% після впровадження рекомендацій.
- Аналіз архітектури та профілю навантаження вашого магазину.
- Розробка реалістичних сценаріїв (каталог, пошук, кошик, checkout).
- Запуск тестів на staging або production (з узгодженням).
- Збір метрик та профілювання (xhprof, slow query, OPcache).
- Детальний звіт з метриками, вузькими місцями та рекомендаціями.
- План першочергових оптимізацій з оцінкою трудозатрат.
- Консультація інженера за результатами.
Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт за 1-2 дні. Замовте тестування перед розпродажами, щоб уникнути втрати виручки.