Привет, Хабр! Меня зовут Эдуард, я руковожу отделом DevOps в компании KISLOROD. В этой статье расскажу про подход к нагрузочному тестированию, который сформировался у нас. Мы постоянно дорабатываем процессы, поэтому буду рад конструктивным комментариям и обмену опытом.

Зачем вообще нужно нагрузочное тестирование

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

Почему это важно? Потому что узнавать о проблемах на пике трафика — худший сценарий. Например, в одном из проектов мы тестировали интернет-магазин перед крупной распродажей. Сайт начинал «падать» уже при нагрузке на 150 % выше обычной. После оптимизации проект выдерживал в 3–4 раза больше, чем до тестов. Без этого этапа компания рисковала потерять не только продажи, но и доверие покупателей.

Что дает нагрузочное тестирование:

• помогает найти узкие места в коде и архитектуре;

• показывает границы производительности и помогает подготовиться к пиковым нагрузкам.

• выявляет долгосрочные проблемы: утечки памяти, деградацию производительности при длительной работе.

• помогает планировать масштабирование и оценивать, куда расти дальше.

• дает измеримые метрики — время отклика, пропускную способность (RPS), использование ресурсов.

Виды нагрузочного тестирования

Разные сценарии тестирования отвечают на разные инженерные вопросы: где граница производительности, когда начинаются отказы и как система поведет себя через сутки под нагрузкой? На эти вопросы отвечают три типа нагрузочных тестов:

1. Load Testing (классическое нагрузочное).

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

Как проводится: нагрузка постепенно растет — от 100 % до 300 % текущего пикового значения. На каждом этапе фиксируются метрики: время отклика, использование CPU, RAM и диска.

Что дает:

• показывает границы производительности системы;

• определяет максимальное количество одновременных пользователей;

• помогает выявить первые точки отказа.

• 2. Stress Testing (стрессовое тестирование).

2. Stress Testing (стрессовое тестирование).

Цель: довести систему до предела и зафиксировать момент, когда она перестает справляться.

Как проводится: нагрузку увеличивают до 150–300 % и удерживают в течение длительного времени (до 12 часов). Так выявляют утечки памяти, ошибки обработки, деградацию производительности при нехватке ресурсов.

Что дает:

• понимание пороговых значений отказа;

• данные о самых узких местах инфраструктуры.

3. Stability Testing (тестирование стабильности).

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

Как проводится: система работает 24 часа и больше при уровне нагрузки 100–120 % от среднего. Наблюдаем за утечками памяти, зависаниями и постепенной деградацией сервисов.

Что дает:

• уверенность, что система останется стабильной даже после недели непрерывной работы;

• понимание, как ведут себя долгоживущие процессы и кеши.

Как мы проводим нагрузочное тестирование:

Этап 1. Сбор и анализ данных

Нагрузочное тестирование начинается с аналитики. Нужно понять, как система работает в данный момент и какие сценарии реально отражают пользовательское поведение. Что анализируем:

• Яндекс.Метрику / Google Analytics: посещаемость, пиковые часы, популярные страницы, источники трафика;

• лог-файлы: веб-серверы (nginx/Apache), PHP, MySQ;

• мониторинг: текущая утилизация CPU, RAM, Disk I/O;

• документацию по проекту: ТЗ от клиента и прочие данные.

По итогам анализа определяются текущие показатели системы.

Этап 2. Подготовка тестового стенда.

Чтобы результаты нагрузочного тестирования имели смысл, стенд должен быть идентичен продакшну — полностью совпадающим по конфигурации. Какие данные должны совпадать:

• характеристики серверов;

• версии операционной системы и программных компонентов;

• конфигурации приложений;

• сетевая инфраструктура.

Перед запуском тестов проверяем базовое состояние среды: свободное место на дисках, загрузку CPU и RAM в состоянии покоя, наличие фоновых процессов, которые могут повлиять на результаты.

Если проект работает на 1С-Битрикс, дополнительно используем встроенную диагностику и отключаем все, что может исказить картину:

• блокировку пользователей при высокой активности («Веб-аналитика»);

• проактивную защиту;

• внешние API (DaData, Google ReCaptcha и др.) — временно заменяем моками или отключаем.

Для имитации реальной активности готовим тестовые данные в формате CSV:  свойства для оформления заказов, параметры фильтрации, список тестовых пользователей.

Этап 3. Создание сценариев тестирования.

Сценарии — основа нагрузочного тестирования. Именно они определяют, насколько точно тест имитирует реальное поведение пользователей.

В зависимости от целей моделируем разные ситуации:

• резкий скачок трафика;

• массовые запросы с одного IP (имитация DDoS);

• всплеск новых регистраций или одновременных покупок.

Цели формулируем конкретно. Ставим задачу, например: «сайт должен выдержать 500 000 одновременных посетителей», «время отклика базы данных не выше 300 мс при RPS = 1000».

Сценарии всегда подстраиваются под проект. Охватить все варианты за один тест невозможно, поэтому движемся поэтапно — от базовых пользовательских путей к стрессовым ситуациям.

Важно включать не только успешные кейсы, но и негативные сценарии, например, неверные данные в формах, поиск по несуществующим товарам или попытки доступа к закрытым страницам.

Минимальный набор цепочек:

1. Главная страница.

2. Категория товаров.

3. Карточка товара.

4. Корзина (с разным количеством позиций).

5. Оформление заказа.

6. Личный кабинет.

7. Постраничная навигация (особенно последние страницы каталога).

8. Контентные разделы — блог, статьи, новости.

Чтобы определить приоритеты, используем:

• данные из аналитики: Яндекс.Метрика → Отчеты → Страницы входа / Популярные страницы;

• логи Nginx — топ самых частых URL;

• типичные пользовательские пути: Карточка → Корзина → Оформление заказа.

Сценарии реализуем в JMeter. Каждая цепочка — это набор HTTP-запросов с параметрами, задержками между действиями, куками и сессиями. Так удается максимально приблизить нагрузку к поведению живых пользователей.

Этап 4. Прогрев системы

Перед основным тестом систему нужно прогреть. Этот этап часто пропускают, но без него результаты будут искажены. Мы выдерживаем стенд под нагрузкой не менее часа — примерно на уровне 75 % от планируемого пика RPS.

На этом этапе важно не менять код и конфигурации, даже если находим ошибки. Любые исправления вносятся только после завершения тестирования и повторного анализа метрик.

После запуска нагрузки проверяем, что система работает в штатном режиме: сервисы откликаются, ресурсы не на пределе, а поведение приложений соответствует ожидаемому.

Этап 5. Запуск тестов

Для проведения тестов используем связку инструментов:

• JMeter — генерация нагрузки;

• Yandex Load Testing — оркестрация сценариев;

• Zabbix — сбор и визуализация метрик.

Процесс:

1. Загружаем сценарии из JMeter в Yandex Load Testing.

2. Настраиваем профиль нагрузки: количество виртуальных пользователей, целевой RPS, длительность теста.

3. Запускаем тест — обычно по 15 минут на каждый уровень нагрузки.

4. В реальном времени отслеживаем метрики в Zabbix:загрузку CPU и RAM,
   Disk I/O и сетевую активность, количество соединений к базе данных,
   среднее время отклика.

На реперных точках (100 %, 200 %, 300 % от номинальной нагрузки) вручную проверяем работоспособность сайта. Автоматические проверки не всегда замечают «мягкие» деградации — страница может возвращать 200 OK, но часть контента не загрузится. 

Тест останавливаем по достижении целевой нагрузки или при отказе системы.

Этап 6. Анализ результатов и формирование рекомендаций.

После завершения тестов переходим к анализу данных. Основное внимание — на время отклика, долю ошибок и число медленных запросов.

Результаты оформляем в виде графиков (Zabbix, Grafana) и сводных таблиц. Задача — понять поведение системы: что именно стало узким местом и при каких условиях.

Пример интерпретации: при нагрузке 250 RPS среднее время отклика выросло с 300 мс до 1,5 с. Анализ показал: узкое место — запрос к таблице товаров.
CPU загружен на 45 %, RAM — на 60 %, значит, проблема не в инфраструктуре, а в коде.

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

Инструменты нагрузочного тестирования: краткий обзор

Каждый инструмент в нагрузочном тестировании хорош по-своему. Мы собрали короткий обзор, чтобы проще было выбрать под задачу:

Мы используем проверенную связку инструментов:

• JMeter — для создания и отладки сценариев нагрузочного тестирования;

• Yandex Load Testing — для оркестрации и масштабирования генераторов нагрузки;

• Zabbix — для мониторинга метрик инфраструктуры в реальном времени;

• ELK (Elasticsearch, Logstash, Kibana) — для агрегации и анализа логов.

Такой набор позволяет контролировать весь процесс — от генерации нагрузки до разбора причин просадок производительности. Более подробно читайте в нашем блоге.

Как это работает на практике: реальный кейс, как мы подготовили интернет-магазин к Черной пятнице

Клиент готовился к масштабной акции. Текущий пик нагрузки — 150 RPS, прогноз после запуска рекламы — до 500 RPS.

Что сделали:

• собрали статистику за три месяца: посещаемость, популярные страницы, пользовательские пути;

• подняли копию продакшена на том же хостинге;

• создали восемь сценариев тестирования, покрывающих ключевые пользовательские флоу;

• провели прогрев стенда (1 час при 100 RPS);

• запустили нагрузку с шагом 50 RPS: 100 → 150 → 200 → 250 → 300 → 350.

Результаты:

• на 250 RPS время отклика выросло с 300 мс до 1,5 с.

• на 300 RPS начались таймауты к БД;

• выявили узкое место — неоптимизированные запросы в модуле фильтрации товаров.

После теста:

• добавили составной индекс в БД;

• кэшировали результаты фильтрации в Redis;

• оптимизировали PHP-код.

В повторном тестировании система выдержала 500 RPS со временем отклика <400 мс. В итоге Черная пятница прошла без сбоев и деградации производительности.

Чек-лист: что нужно для успешного нагрузочного тестирования

1. Соберите аналитику — трафик, популярные страницы, пиковые часы.

2. Разверните тестовый стенд, полностью идентичный продакшену.

3. Отключите внешние API и защиты, которые могут исказить результаты.

4. Создайте сценарии тестирования, охватывающие ключевые пользовательские цепочки.

5. Настройте мониторинг — Zabbix, Grafana или аналоги.

6. Выполните прогрев системы перед основными тестами.

7. Запустите тесты с разными уровнями нагрузки.

8. Зафиксируйте метрики и определите узкие места.

9. Подготовьте отчет с приоритизированными рекомендациями.

10. Внесите изменения в бэклог и реализуйте их.

Нагрузочное тестирование показывает, как система ведет себя в реальных условиях — под наплывом пользователей, на пиках продаж, в моменты, когда все должно работать без сбоев. Это инструмент, который помогает заранее увидеть слабые места и подготовиться, пока не начался аврал. Потраченное время окупается уверенностью: в день Х система не подведет ни команду, ни бизнес.

Буду рад вашим вопросам и историям в комментариях — обмен опытом всегда полезен!

Подробнее о мониторинге производительности системы читайте в нашем блоге.