Тебе впервые сказали провести нагрузочное тестирование. С какого бока к этому вообще подойти?
Какой вопрос должен закрыть тест?
С нагрузочным тестированием есть одна неприятная особенность. Даже когда все поняли, что оно необходимо, часто тестировщику задача приходит в виде:
«Ну, мы должны понять, сколько пользователей выдержит система»
или:
«Надо проверить нагрузку».
На этом этапе хочется открыть JMeter, k6 или любой другой генератор, выставить несколько сотен виртуальных пользователей и посмотреть, что произойдёт. Но проблема в том, что запускать пока нечего.
Мы ещё не определили:
какую нагрузку собираемся воспроизводить;
что именно хотим узнать;
по каким признакам будем оценивать результат.
Проверка нагрузки сама по себе целью не является, потому что нагрузочные тесты могут отвечать на совершенно разные вопросы.
Допустим, у нас есть сервис интернет‑магазина, который готовится к релизу. От бизнеса приходит задача узнать, сколько пользователей он сможет обслуживать одновременно.
Первое, что стоит уточнить: зачем нужна эта цифра?
Команда может хотеть проверить, выдерживает ли система ожидаемый трафик после запуска. Или понять, где находится её предел. Возможно, через неделю планируется рекламная кампания и нужно узнать, что произойдёт во время резкого всплеска. А иногда проблема уже известна: при росте нагрузки сервис начинает тормозить, и тест нужен, чтобы найти узкое место.
Как видите, это разные задачи, поэтому и планы для них будут разными.
Для примера мы можем сформулировать цель так:
Определить рабочую нагрузку, при которой основные пользовательские сценарии интернет‑магазина выполняются без существенного роста времени ответа и количества ошибок.
Это все еще не идеальная формулировка, потому что существенный рост тоже нужно определить, но здесь уже становится понятно, что мы ищем не момент окончательного падения системы, а диапазон, в котором она остается пригодной для работы.
Количество виртуальных пользователей!= количество реальных пользователей
Следующий вопрос обычно касается самой нагрузки.
Допустим, бизнес ожидает 5000 пользователей. Можно ли просто запустить 5000 виртуальных пользователей?
Нет, потому что само количество пользователей практически ничего не говорит об интенсивности работы системы.
Один пользователь может открыть каталог и пять минут выбирать товар. Другой за то же время выполнит поиск, откроет десять карточек и несколько раз изменит корзину. Третий вообще оставит вкладку открытой и не отправит ни одного запроса.
Поэтому в плане нам нужна не только аудитория, но и модель нагрузки, то есть описание того:
какие операции выполняются;
с какой частотой;
в каких пропорциях.
Для уже работающего продукта лучший источник таких данных обычно находится в самом продакшене. Можно посмотреть:
access‑логи;
аналитику;
число активных пользователей;
количество запросов в часы пик;
распределение запросов между операциями.
Microsoft в рекомендациях по performance testing также предлагает строить сценарии вокруг реального использования системы, включая пользовательские действия, фоновые процессы, интеграции и объёмы данных.
Если продукт новый, реальной статистики ещё нет. Тогда придётся идти к аналитикам, владельцу продукта или бизнесу и собирать прогноз.
Допустим, для нашего магазина выяснилось следующее. Большинство пользователей просматривает каталог, часть пользуется поиском, значительно меньше добавляет товар в корзину, а оформление заказа происходит сравнительно редко.
Это уже позволяет получить условную модель:
Просмотр каталога |
50% |
Поиск |
25% |
Карточка товара |
15% |
Добавление в корзину |
7% |
Оформление заказа |
3% |
Цифры здесь не являются универсальной рекомендацией. Это данные конкретного продукта или, если их пока нет, явно зафиксированное предположение.
Последнее особенно важно. Если бизнес сам не знает ожидаемую интенсивность, тестировщик не обязан угадывать её и потом выдавать результат за объективную характеристику системы.
В плане можно прямо записать, что распределение сценариев принято как предварительное допущение и требует пересмотра после появления реальных данных.
А если требований к производительности вообще нет?
Допустим, мы разобрались с пользовательскими сценариями, но получили новую проблему.
На вопрос
«Какое время ответа допустимо?»
бизнес отвечает:
«Главное, чтобы не тормозило».
Спрашиваем, какая должна быть допустимая доля ошибок, и получаем:
«Ну, желательно без ошибок».
В этот момент очень хочется придумать из этого SLA, но не стоит.
Если команда действительно договорилась, например, что 95% запросов должны выполняться быстрее секунды, это можно использовать как критерий успешности. Но если такого требования нет, выбранная тестировщиком секунда не превращается в бизнес‑требование только потому, что была записана в документ.
В таком случае первый тест разумно сделать исследовательским.
Его задача будет состоять в том, чтобы посмотреть, как меняется поведение системы по мере увеличения нагрузки и найти область, в которой начинается заметная деградация.
Например:
при 50 запросах в секунду p95 равен 300 мс, ошибок нет, система использует половину доступных ресурсов;
при 100 запросах в секунду p95 увеличивается до 450 мс;
при 150 начинает расти очередь соединений к базе, p95 достигает 1,2 секунды;
при 180 появляются ошибки.
Такой тест дает фактическую характеристику системы и материал для принятия решений.
Проверить, насколько уверенно вы ориентируетесь в нагрузочном тестировании, можно с помощью вступительного теста. Он поможет определить текущий уровень и увидеть темы, которые стоит разобрать глубже.
Выбираем, что именно будем воспроизводить
Теперь можно переходить от бизнес‑сценариев к тестовым.
Необязательно в первом нагрузочном тесте моделировать каждую кнопку продукта. Лучше взять несколько операций, которые действительно создают значимую нагрузку или критичны для бизнеса.
Для магазина это могут быть:
просмотр каталога;
поиск;
добавление товара в корзину;
оформление заказа.
При этом одного HTTP‑запроса зачастую недостаточно, чтобы представить реального пользователя.
Например, оформление заказа может включать:
авторизацию;
получение корзины;
проверку остатков;
создание заказа.
Такие связанные действия имеет смысл рассматривать как один сценарий.
Нужно учитывать и паузы между действиями. Настоящий пользователь не открывает карточку товара и в ту же миллисекунду оформляет заказ. Если убрать время на чтение и выбор, генератор создаст профиль, которого в реальности может никогда не существовать.
Здесь же стоит определить тестовые данные. Если все виртуальные пользователи авторизуются под одной учётной записью и покупают один товар, мы можем случайно измерить особенности кэша, блокировок или конкретной записи вместо поведения системы в реальном режиме.
Полезный вопрос на этом этапе звучит так:
Что должно происходить в системе, чтобы создаваемая нами нагрузка была похожа на ту, ради которой мы вообще проводим тест?
Строим профиль нагрузки
Когда сценарии определены, нужно решить, как нагрузка будет меняться во времени.
Для первого теста сложная схема обычно не нужна. Достаточно:
постепенного разгона;
периода стабильной нагрузки;
снижения.
Например:
5 минут — постепенный рост нагрузки;
15 минут — работа на целевом уровне;
10 минут — повышенная нагрузка;
5 минут — снижение нагрузки.
Плавный разгон нужен не ради красивого графика. Он позволяет увидеть, как показатели изменяются вместе с нагрузкой, и не смешивать нормальную работу системы с эффектом одномоментного запуска большого числа клиентов.
Grafana в своих рекомендациях также использует базовый профиль из ramp‑up, steady state и ramp‑down, то есть постепенного увеличения, стабильного участка и снижения нагрузки.
Если наша первоначальная задача звучала как «узнать, сколько пользователей выдержим», можно провести несколько последовательных ступеней. Например, увеличивать нагрузку до тех пор, пока не начнётся явная деградация, а затем провести дополнительные прогоны около найденной границы.
Здесь важно не перепутать максимальную и рабочую нагрузку.
Момент, когда сервер окончательно перестал отвечать, редко является полезной бизнесу цифрой. Гораздо интереснее уровень, после которого дальнейший рост нагрузки начинает непропорционально увеличивать:
задержки;
ошибки;
потребление ограниченного ресурса.
AWS отдельно рекомендует проверять систему не только на ожидаемой нагрузке, но и выше неё, чтобы увидеть, где начинаются проблемы. При этом инфраструктура тестового окружения должна быть сопоставима с production, иначе переносить полученные цифры на реальную систему нужно очень осторожно.
Заранее решаем, что будем измерять
Распространенная ошибка — закончить план на описании:
«Запускаем 500 пользователей на 30 минут».
После этих 30 минут нужно будет ответить, что произошло.
Со стороны клиента обычно нас интересуют:
время ответа;
интенсивность успешно выполненных операций;
количество ошибок.
Среднего времени ответа для анализа мало, потому что оно может скрывать небольшую долю очень медленных запросов. Поэтому обычно смотрят в том числе на перцентили, например p95 или p99.
p95 в данном случае означает, что 95% измеренных запросов завершились не медленнее указанного значения.
Одновременно нужны серверные метрики. Иначе мы узнаем, что запросы стали медленнее, но не узнаем почему.
Для одного продукта ограничением может оказаться:
CPU;
пул соединений с базой данных;
очередь сообщений;
память;
дисковые операции;
внешняя зависимость.
У Google SRE есть удобная базовая модель наблюдения за сервисом:
latency;
traffic;
errors;
saturation.
Последнее означает степень насыщения ограниченного ресурса системы. Google отдельно отмечает, что рост высокой перцентили latency может быть ранним признаком приближения к насыщению.
Для первого плана этого уровня детализации обычно достаточно. Не нужно заранее собирать сотни метрик. Нужно понимать, какие показатели позволят отличить нормальную работу от деградации и хотя бы приблизительно локализовать причину.
Не забываем про стенд
Результат нагрузочного теста всегда относится не только к приложению, но и к конфигурации, на которой оно работало.
Тестовый стенд может использовать один экземпляр приложения и базу с 2 ГБ памяти, а прод состоит из четырёх экземпляров, балансировщика и значительно более мощной базы.
Поэтому в плане стоит зафиксировать:
конфигурацию среды;
версии приложения и основных зависимостей;
объём данных;
отличия от production.
Microsoft и AWS также рекомендуют проводить performance‑тестирование в среде, максимально близкой к рабочей, и учитывать различия при интерпретации результатов.
Это не означает, что нагрузочное тестирование имеет смысл только на полной копии production. Небольшой стенд тоже может показать регрессии или помочь найти узкое место. Просто вывод должен соответствовать тому, что мы действительно проверили.
Что в итоге должно получиться до запуска теста
Вернемся к исходной задаче.
Нужно посмотреть, сколько пользователей выдержит система.
После нескольких уточнений у нас уже может появиться план примерно такого вида:
1. Цель Определить диапазон рабочей нагрузки сервиса и точку, после которой начинается заметная деградация. 2. Сценарии 50% — просмотр каталога 25% — поиск 15% — просмотр товара 7% — добавление в корзину 3% — оформление заказа 3. Источник данных о нагрузке Production-статистики пока нет. Распределение сценариев является предварительным допущением. 4. Профиль нагрузки - постепенный разгон; - работа на нескольких ступенях нагрузки; - снижение нагрузки; - проверка восстановления системы. 5. Метрики со стороны клиента - Throughput; - Error rate; - p95; - p99. 6. Метрики системы - CPU; - RAM; - соединения с БД; - очереди. 7. Критерии оценки Формального SLA нет, поэтому тест является исследовательским. Ищем участок, на котором начинают заметно расти: - время ответа; - количество ошибок; - насыщение ресурсов. 8. Стенд Фиксируем: - конфигурацию приложения; - конфигурацию базы данных; - количество экземпляров сервисов; - основные отличия от production. 9. Ожидаемый результат - диапазон стабильной работы; - область начала деградации; - предполагаемое узкое место; - ограничения полученных результатов.
Обратите внимание, здесь пока нет ни JMeter, ни k6, ни Gatling. Это нормально. Инструмент нужен для реализации уже понятного теста.
Первый план нагрузочного тестирования не обязан быть большим документом. Для небольшой системы он вполне может занимать одну страницу.
Особенно важно не маскировать отсутствие требований придуманной точностью. Если бизнес не знает будущую нагрузку или допустимое время ответа, это не делает тест невозможным. Можно провести исследовательский прогон, зафиксировать допущения и получить реальные характеристики системы.
В таком случае результатом первого нагрузочного тестирования будет не красивая цифра, а гораздо более полезное утверждение. Какую нагрузку мы воспроизвели, как система на неё отреагировала, где началась деградация и насколько уверенно эти выводы можно переносить на прод.
Когда теория уже складывается в план, но не хватает практического понимания, полезно разобрать первый нагрузочный тест по шагам: от постановки цели и сценариев до метрик и интерпретации результатов.
На открытых уроках можно также сверить свои знания с требованиями работодателей и понять, какие навыки действительно нужны нагрузочному тестировщику, чтобы увереннее переходить от пробных запусков к полноценной работе.
30 июля в 20:00. «Прохождение собеседования на нагрузочного тестировщика. Что интересует работодателя?». Записаться
13 августа в 20:00. «Минимум для старта: как провести свое первое нагрузочное тестирование». Записаться
Больше бесплатных уроков и других полезных подборок смотрите в дайджесте.