Нагрузочное тестирование веб-приложения: как подготовиться и не получить ложный результат
Нагрузочное тестирование отвечает не на вопрос «выдержит ли сайт много посетителей», а на более полезный: какие реальные действия пользователей система выполнит с согласованным качеством и где она перестанет это делать. Без сценариев и метрик тест легко превращается в красивый график, по которому невозможно принять техническое решение.
В этой статье собрали рабочий порядок подготовки. Он подойдёт для интернет-магазина, личного кабинета, B2B-портала или API. Если нужно не только провести тест, но и исправить ограничения в архитектуре, это входит в работу по разработке высоконагруженных систем.
1. Начните с цели теста
Фраза «проверим под нагрузкой» слишком расплывчата. У теста должна быть одна или несколько проверяемых целей:
- выдержать запуск рекламы без деградации оформления заказа;
- проверить, как API ведёт себя при параллельной загрузке данных партнёрами;
- понять, выдержит ли личный кабинет отчётный период;
- сравнить состояние системы до и после оптимизации;
- найти предел, после которого требуется масштабирование или ограничение части функций.
Цель определяет все остальные решения: какие сценарии включать, сколько виртуальных пользователей запускать, какие метрики считать успешными и что делать с результатами.
2. Выберите не страницы, а бизнес-сценарии
Проверка одной главной страницы почти ничего не говорит о надёжности продукта. Пользовательский сценарий состоит из цепочки действий и зависимостей. Для магазина это может быть поиск товара, добавление в корзину, расчёт доставки, резервирование и оплата. Для B2B-сервиса - вход, получение списка, работа с документом, обмен с учётной системой и уведомление.
Для каждого сценария зафиксируйте:
- Кто его выполняет и как часто.
- Какие запросы и внешние системы участвуют.
- Какое время ответа считается приемлемым.
- Что считать ошибкой: HTTP-статус, таймаут, неверные данные, потерянное событие.
- Что происходит при временной недоступности внешней зависимости.
Это особенно важно для систем с очередями и API. Нагрузка может выглядеть нормально на фронтенде, но копиться в фоновых задачах и проявиться спустя час после теста.
3. Подготовьте похожие на реальные данные
Пустая тестовая база часто даёт ложный оптимизм. Запрос, который быстро работает на сотне записей, может вести себя иначе на рабочем объёме с фильтрами, правами доступа и связями между сущностями.
Не нужно копировать персональные данные в тестовый контур. Достаточно подготовить анонимизированные или синтетические наборы с похожим объёмом и распределением: активные и архивные записи, популярные товары, длинная история операций, несколько ролей пользователей. Отдельно проверьте сценарии конкуренции за один ресурс: остаток товара, слот записи, документ или общий лимит.
4. Согласуйте метрики до запуска
Хороший отчёт не ограничивается средней скоростью ответа. Среднее значение может скрывать ситуацию, в которой часть пользователей ждёт слишком долго. Обычно полезно смотреть:
- время ответа по перцентилям для каждого критичного сценария;
- долю ошибок и типы ошибок;
- скорость обработки очередей и число повторных попыток;
- загрузку процессора, памяти, сети и диска;
- состояние базы данных: медленные запросы, блокировки, соединения, индексы;
- внешние зависимости и их таймауты;
- бизнес-результат: завершились ли заказы, не появились ли дубли или потерянные операции.
Целевые показатели лучше обсуждать вместе с владельцем продукта. Подход к таким показателям в эксплуатационных системах описан в руководстве Google SRE по SLO.
5. Проведите несколько типов тестов
Один «максимальный» прогон редко даёт полную картину. Для практической оценки обычно нужны разные режимы:
- базовый тест - подтверждает, что сценарий работает без заметной нагрузки;
- плавный рост - показывает, на каком уровне начинают расти задержки и ошибки;
- пиковый тест - имитирует краткий всплеск спроса;
- длительный тест - выявляет утечки памяти, накопление очередей и деградацию со временем;
- тест отказа зависимости - проверяет поведение при задержке или недоступности внешнего API.
Важно увеличивать нагрузку контролируемо и сохранять конфигурацию каждого прогона. Тогда после исправлений можно повторить ровно тот же сценарий и честно сравнить результат.
6. Не останавливайтесь на списке проблем
Тест полезен только тогда, когда на его основе появляется план. У каждой находки должны быть: причина или гипотеза, влияние на сценарий, приоритет, способ проверки после исправления и владелец действия.
Например, тяжёлый запрос можно решить индексом, переписыванием выборки, кэшированием или выносом отчёта из транзакционного контура. Синхронную интеграцию - очередью, повторными попытками и идемпотентной обработкой. Выбор зависит от требований к консистентности и пользовательскому пути.
В проекте OfficeScanner взаимодействуют сделки, документы, телефония, маркетинговые каналы и аналитика. Для подобных систем нагрузочный разбор должен учитывать не один экран, а цепочку интеграций и работу с данными по ролям.
Типовые ошибки при нагрузочном тестировании
Сразу тестировать «на максимум»
Без базовой линии невозможно понять, с какого момента система деградирует и что изменилось после исправления. Начинайте с ожидаемого обычного профиля, затем наращивайте поток.
Подменять внешние системы без фиксации этого факта
Моки полезны, если сторонний сервис нельзя нагружать. Но тогда результат относится к вашему контуру, а не к полному пользовательскому пути. Это нужно явно зафиксировать в отчёте.
Смотреть только на HTTP 200
Запрос может завершиться успешно, но создать дубликат, задержать сообщение в очереди или вернуть устаревшие данные. Добавляйте проверки бизнес-результата.
Делать вывод «нужны микросервисы» по одному графику
Причина может находиться в базе данных, кэше, интеграции или коде одного обработчика. Микросервисы оправданы не как автоматический ответ на нагрузку, а когда отдельным частям продукта нужно независимое масштабирование и выпуск изменений. Подробнее - в материале «Монолит или микросервисы».
Чек-лист перед запуском
- Критичные сценарии и их приоритет согласованы с бизнесом.
- Тестовые данные похожи на реальный объём и не содержат персональных данных.
- Зафиксированы целевые задержки, ошибки и бизнес-проверки.
- Подключены метрики приложения, базы, очередей, инфраструктуры и внешних зависимостей.
- Известно, где запускается тест и как он не повлияет на пользователей.
- Есть владелец разбора результатов и дата повторной проверки после исправлений.
Если часть этих пунктов пока не ясна, начните с аудита highload-системы. Он помогает превратить «нужно проверить производительность» в сценарии, метрики и последовательный план работ.
FAQ
Как часто проводить нагрузочное тестирование?
Перед ожидаемыми пиками, крупными релизами, миграциями и изменениями в критичных интеграциях. Для важных сценариев полезно повторять тесты регулярно, чтобы видеть регрессии до продакшена.
Можно ли тестировать production?
Иногда проводят ограниченные проверки в production с заранее согласованными лимитами и наблюдением. Но основной нагрузочный эксперимент безопаснее выполнять в близком к production контуре, чтобы не рисковать данными и пользователями.
Чем проводить нагрузочное тестирование?
Инструмент выбирают под протокол и сценарии. Важнее корректно описать поток, данные и проверки, чем выбрать конкретное название инструмента. Например, в документации Grafana k6 подробно описаны распространённые типы тестов.