Нагрузочное тестирование сервера: рабочие приёмы без самообмана

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

Если сервер выдержал тысячу виртуальных пользователей в k6, это ещё не означает, что он выдержит тысячу реальных клиентов. Результат зависит от сценария, длительности теста, генератора нагрузки и того, что вы измеряете. Проверка «давайте отправим побольше запросов» часто показывает лишь, что первым закончились ресурсы на машине, с которой запускают тест.

Практический подход — сравнить несколько режимов на одном и том же пользовательском действии: короткий всплеск, постепенный рост и длительная нагрузка. Так вы увидите не только максимальную пропускную способность, но и момент, когда растёт задержка или начинают появляться ошибки. Примеры ниже рассчитаны на k6 0.49.0 и HTTP-сервис; для других версий сверьте параметры с документацией.

Сначала зафиксируйте условия

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

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

Виртуальный пользователь (VU) — участник сценария в нагрузочном тесте. Это не обязательно один реальный человек: VU исполняет заданные действия с тем темпом, который задаёт сценарий.

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

Три режима — три разных ответа

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

Сценарий для k6: ступенчатый рост

Этот пример запускает один HTTP-запрос на итерацию. Замените адрес и путь на тестовый endpoint, доступный из среды запуска. Пороговые значения приведены как шаблон, а не как норматив: задайте их по требованиям вашего сервиса. Файл можно сохранить как load-test.js и запустить командой k6 run load-test.js с установленным k6 0.49.0.

import http from 'k6/http';
import { check } from 'k6';

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

export default function () {
  const response = http.get('https://test.example.com/health');
  check(response, {
    'status is 200': (result) => result.status === 200,
  });
}

В этом сценарии число VU сначала растёт до 10, остаётся на этом уровне, затем увеличивается до 30 и снова стабилизируется. Порог для http_req_duration проверяет 95-й перцентиль задержки, а не среднее значение: среднее может скрыть медленные ответы небольшой части пользователей. Адрес test.example.com — пример-заглушка, укажите свой тестовый адрес.

Читайте результат вместе с метриками сервера

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

Если клиент показывает ошибки, а ресурсы приложения почти не заняты, проверьте генератор, сеть и балансировщик. Если растут задержки вместе с загрузкой CPU, ищите дорогие операции в приложении. Если приложение ждёт базу, проверьте запросы, блокировки и пул соединений. Это направления диагностики, а не готовый диагноз: одни и те же симптомы могут иметь разные причины.

Не путайте поток запросов и число пользователей

При модели с VU один пользователь начинает следующую итерацию после завершения предыдущей. Поэтому замедление сервера может снизить скорость отправки запросов: тест сам уменьшит давление на систему. Это важно, если задача — выдержать заданную частоту запросов. В таком случае выберите модель и настройки, которые поддерживают целевой темп, и проверьте в отчёте, что генератор действительно его достиг. Документация k6 описывает различия между сценариями и исполнителями.

Что ломает тест и когда менять подход

• Генератор стал узким местом. Процессор машины-тестера загружен, а целевой сервер не получает ожидаемый поток. Запустите тест с другой машины или распределите генерацию; сначала убедитесь, что новый генератор сам справляется.
• Тестовые данные не похожи на рабочие. Одна и та же запись может попадать в кэш, тогда как реальные запросы обращаются к разным данным. Подготовьте безопасный набор с подходящим распределением.
• Прогон слишком короткий. Он показывает быстрый отклик, но может не выявить постепенный рост памяти или очередей. Увеличьте длительность стабильного этапа и следите за динамикой.
• Сравниваются разные условия. Если поменялись версия приложения, конфигурация или объём данных, нельзя приписывать разницу одному изменению. Фиксируйте параметры и меняйте за прогон только то, что хотите проверить.
• Продакшен получил неожиданный трафик. Не запускайте тест там без согласования с владельцами сервиса и плана остановки. Внешние интеграции и общие базы могут пострадать раньше, чем тестируемый сервер.

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

Что делать дальше

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