Ваше приложение прекрасно работает с десятью пользователями. Что произойдет в день распродажи с десятью тысячами? Нагрузочное тестирование и стресс-тестирование описывают два разных способа ответа на этот вопрос, и их смешение приводит к тестам, которые не доказывают то, что, по вашему мнению, они делают.

В этом руководстве объясняется, что показывает каждый из них, связанные типы тестов и как читать результаты. Ниже мы выполнили небольшой расчет процентиля на Python 3.13 с смоделированными числами. Скрипты k6 — это наглядные примеры, которые мы не выполняли, а количество пользователей и цели придуманы, поэтому замените их своими. Запускайте эти тесты только на тех системах, которыми вы владеете или имеете разрешение на тестирование, поскольку большой трафик может выглядеть как атака и вызывать реальные сбои.

Короткий ответ

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

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

Нагрузочное тестирование и стресс-тестирование бок о бок

Что такое нагрузочное тестирование?

Нагрузочное тестирование имитирует ожидаемый реалистичный трафик и измеряет поведение системы. Ему нужна цель для тестирования, например: «при 500 одновременных пользователях 95% запросов на оформление завершаются в течение 800 мс, с ошибками менее 1%.»

Вот как это может выглядеть в виде сценария k6. Тесты k6 написаны на JavaScript и thresholds превращают ваши цели в результат «пройден» или «не пройден»:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

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

Что такое стресс-тестирование?

Стресс-тестирование намеренно выходит за рамки ожидаемых уровней. Вы не пытаетесь пройти. Вам нужны ответы на такие вопросы, как:

• На каком уровне производительность начинает падать?
• Какой компонент выходит из строя первым: база данных, серверы приложений или сторонний вызов?
• Происходит ли он корректно с явными ошибками или происходит сбой и потеря данных?
• Восстанавливается ли он сам при падении трафика?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

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

Шип, замачивание и другие типы

Нагрузочные и стресс-тесты относятся к более широкому семейству тестов производительности:

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

Метрики, которые имеют значение

Почему средние значения вводят в заблуждение

Средние значения скрывают медленные запросы, на которые жалуются реальные люди. Чтобы продемонстрировать это, мы сгенерировали 100 смоделированных времен отклика, из которых 95 были быстрыми (от 80 до 200 мс), а 5 — очень медленными (от 2,5 до 4 секунд), а затем рассчитали общую статистику:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Посмотрите внимательно на эти цифры. Среднее значение 302 мс никого не характеризует. Типичные запросы занимали около 150 мс, а медленные — более 3 секунд. Даже p95 выглядит здоровым на 199 мс, и только p99 выявляет проблему. Такая цифра, как p95, означает, что 95% запросов были такими же быстрыми или быстрее.

И один процент запросов – явление не редкое. Если страница отправляет 50 запросов, медленный p99 влияет на большую долю просмотров страниц. Установите цели для важных для вас процентилей и рассмотрите несколько из них вместе.

Инструменты

Любой из них может запускать как нагрузочные, так и стресс-тесты. Выберите тот, который соответствует навыкам вашей команды, а не гонитесь за списком функций. Чтобы использовать его в своем конвейере, см. что такое CI/CD.

Как спланировать тест

1. Установите цели. Используйте реальную аналитику, чтобы определить пиковый трафик и определить цели.
2. Выбирайте путешествия. Моделируйте реалистичное поведение пользователей, например просмотр, поиск и оформление заказа, в реалистичных пропорциях. Посещение только домашней страницы мало что доказывает.
3. Используйте реалистичную среду. Крошечный промежуточный сервер не может предсказать производительность. Обратите внимание на любые различия.
4. Подготовьте данные. Используйте реалистичные объемы, поскольку запрос, который быстро обрабатывает 100 строк, может просканировать 10 миллионов.
5. Предупредите людей. Сообщите об этом своей операционной команде и третьим лицам и не запускайте случайное нагрузочное тестирование платежной системы. Имитируйте внешние сервисы, где это возможно.
6. Начните с малого. Сначала проведите небольшой дым-тест, чтобы убедиться, что ваш скрипт работает.
7. Мониторьте все. Без показателей сервера вы увидите, что он замедлился, но не почему.
8. Повторите. Запускайте его снова после каждого исправления и сохраняйте базовый уровень для сравнения.

Чтение результатов

Базы данных являются распространенным узким местом, поэтому, если проблема связана с запросами, прочитайте наше руководство по оптимизации SQL-запросов. Эта последняя строка таблицы является важной ловушкой: всегда проверяйте также исправность машины, генерирующей нагрузку.

Распространенные ошибки

• Запутывает пользователей запросами. Уточните, означает ли цель количество одновременных пользователей или количество запросов в секунду.
• Не хватает времени на размышления. Это увеличивает трафик и приводит к вводящим в заблуждение результатам.
• Тестирование слишком позднее. Неделя до запуска не оставляет времени на исправление проблем с архитектурой.
• Использование одной конечной точки. Реальный трафик смешивает операции чтения, записи и поиска.
• Кэширование скрывает всё. Идентичные повторяющиеся запросы могут только проверить ваш кеш, поэтому меняйте данные.
• Тестирование один раз. Производительность меняется с каждым выпуском, поэтому запускайте тесты регулярно.

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться