Нагрузочное тестирование: как узнать, выдержит ли сайт наплыв пользователей

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

Разберём, какие бывают тесты, как составить реалистичный сценарий, какие метрики смотреть и что делать с результатами.

Какие бывают виды нагрузочных тестов?

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

Вид теста	Вопрос	Как проводят
Нагрузочный	Выдержит ли система ожидаемый пик	Плавно выходят на целевую нагрузку и держат её
Стрессовый	Где предел и как система ломается	Наращивают нагрузку до отказа
Пиковый (spike)	Переживёт ли система резкий всплеск	Мгновенно увеличивают нагрузку в разы
Длительный (soak)	Нет ли утечек памяти и деградации	Держат среднюю нагрузку часами

Как составить реалистичный сценарий?

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

Шаги подготовки:

1. Выберите 3–5 ключевых пользовательских сценариев: просмотр каталога, поиск, корзина, оформление заказа, вход.
2. Возьмите из аналитики долю каждого сценария и паузы между действиями.
3. Определите цель: например, 500 одновременных пользователей и время ответа p95 меньше 500 мс.
4. Подготовьте тестовые данные: пользователей, товары, промокоды.
5. Отключите реальные платежи, SMS и письма — замените их заглушками.

import http from 'k6/http'
import { sleep, check } from 'k6'

export const options = {
  stages: [
    { duration: '5m', target: 500 },
    { duration: '15m', target: 500 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.01'] },
}

export default function () {
  const res = http.get('https://staging.example.com/api/products?page=1')
  check(res, { 'status 200': (r) => r.status === 200 })
  sleep(Math.random() * 3 + 1)
}

Фото: Unsplash

Какие метрики смотреть во время теста?

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

• время ответа в перцентилях p95 и p99, а не среднее;
• доля ошибок и их типы: таймауты, 500, отказ в соединении;
• пропускная способность — сколько запросов в секунду система реально обрабатывает;
• ресурсы — процессор, память, диск, сеть каждого сервера;
• база данных — медленные запросы, блокировки, количество соединений;
• очереди — растёт ли количество задач в ожидании.

Как настроить сбор этих данных, мы разбирали в статье мониторинг и логирование.

Где обычно находится узкое место?

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

Типичные находки:

• запрос без индекса, который незаметен на тестовых данных и тормозит на реальных;
• десятки запросов к базе на одну страницу вместо одного;
• синхронные вызовы внешних API прямо в запросе пользователя;
• нет кеша для каталога и главной страницы;
• лимит соединений с базой или процессов приложения меньше, чем нужно.

Как с этим работать — в статьях индексы в PostgreSQL, кеширование в веб-приложении и очереди задач.

Что делать с результатами теста?

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

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

Коротко

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