Расчет нагрузки

Почему расчет нагрузки – это не «нажать кнопку и посмотреть»

Расчет нагрузки – это фундамент любого нагрузочного тестирования. Без понимания, какую нагрузку ваша система должна выдерживать, вы получите красивый график в консоли, но не ответите на главный вопрос: «А выдержит ли это всё в час пик?»

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

Что такое расчет нагрузки: ключевые метрики

Расчет нагрузки – это определение количественных параметров тестирования: сколько виртуальных пользователей (VUs), какой RPS (Requests Per Second), какую продолжительность теста и профиль нагрузки. Без этих параметров тест превращается в лотерею.

Базовые метрики для расчета:

• VUs (Virtual Users) – количество одновременных виртуальных пользователей. Это не то же самое, что общее число пользователей в день. Если у вас 10 000 пользователей в сутки, но пик – 500 одновременно, используйте 500 как базу.
• RPS (Requests Per Second) – количество запросов в секунду. Один пользователь может генерировать 2-10 запросов в секунду в зависимости от сценария.
• Think Time – время «паузы» между действиями пользователя. Обычно 2-5 секунд для реалистичности.
• Duration – продолжительность теста. Для стабильного теста – минимум 5-10 минут на пиковой нагрузке.

Формула расчета RPS

Простая формула для ориентировочного расчета:

RPS = (VUs × Requests per VU per second)

Пример: 100 VUs, каждый делает 3 запроса в секунду = 300 RPS.

Более точная формула с учетом think time:

RPS = VUs / (Average Response Time + Think Time)

Если среднее время отклика 200мс (0.2с), а think time 3с, то: 100 VUs / (0.2 + 3) = 31.25 RPS на одного пользователя.

Калькулятор параметров нагрузки

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

Типы нагрузочных тестов и когда их применять

Расчет нагрузки зависит от цели тестирования. Вот четыре основных типа:

1. Smoke Test – минимальная нагрузка (5-10 VUs). Проверка, что система вообще работает и не падает сразу.
2. Load Test – ожидаемая пиковая нагрузка. Тестирование при тех значениях, которые система должна обрабатывать в реальности.
3. Stress Test – нагрузка выше ожидаемой. Выяснение предела прочности системы.
4. Spike Test – резкие скачки нагрузки. Проверка, как система реагирует на внезапные всплески трафика.

Инструменты для расчета и проведения нагрузки

k6: современный подход

k6 – современный инструмент с открытым исходным кодом. Простой скрипт на JavaScript, низкое потребление памяти, встроенные дашборды.

Пример простого скрипта:

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

export const options = {
  vus: 100, // 100 виртуальных пользователей
  duration: '10m', // 10 минут
  thresholds: {
    http_req_duration: ['p(95)<500'], // p95 должен быть меньше 500мс
  },
};

export default function () {
  const res = http.get('https://your-api.com/endpoint');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(2); // пауза 2 секунды между запросами
}

Запускается командой k6 run script.js. Результаты выводятся в консоль, но для анализа лучше использовать визуализацию.

4 способа визуализации результатов k6:

• k6-reporter – генерация HTML-отчета одной строкой кода
• Встроенный Web Dashboard – графики в реальном времени на http://127.0.0.1:5665
• InfluxDB + Grafana – полноценный мониторинг с историей
• AI-анализ – экспорт в JSON и анализ через нейросети с построением графиков

Apache JMeter: проверенный инструмент

JMeter – классический инструмент с графическим интерфейсом. Подходит для команд, где тестировщики не пишут код.

Архитектура JMeter:

• Master – управляющий узел с ноутбука
• Slave – Linux-серверы, генерирующие трафик
• Один мастер + несколько слейвов = распределенная генерация нагрузки

Лучшие практики JMeter:

1. Используйте Transaction Controller для группировки бизнес-операций
2. Настраивайте HTTP Header Manager правильно (Accept-Encoding: gzip)
3. Применяйте JSON Extractor или Groovy для извлечения токенов
4. Запускайте тесты в CLI-режиме, не в GUI
5. Генерируйте HTML-отчет командой: jmeter -g result.jtl -o report/

Анализ результатов: на что смотреть

Самая частая ошибка – смотреть только на Average (среднее время). Вот почему это опасно:

Представьте: 99% запросов по 30мс, а 1% – по 12 секунд. Среднее покажет 120мс. Пользователи из этого 1% уже написали гневные тикеты, а вы видите «всё хорошо».

Метрики, которые действительно важны:

• p90, p95, p99 – процентили времени отклика. p95 = 500мс означает, что 95% запросов укладываются в полсекунды.
• TPS (Transactions per Second) – ищите точку насыщения. Момент, когда добавляете VUs, а TPS перестает расти – это предел.
• http_req_failed – процент ошибок. 0% – хорошо, но проверяйте тело ответа, а не только код 200.
• Latency vs Connect Time – высокий Connect Time = проблема на сетевом уровне. Высокая Latency при низком Connect Time = проблема в приложении.

Как понять, что система не справляется

Признаки проблемы в результатах теста:

• p99 резко растет при увеличении VUs
• http_req_failed начинает расти
• TPS выходит на плато или падает
• Время отклика «ползет» вверх в течение теста (возможна утечка памяти)

Частые ошибки при расчете нагрузки

1. Тестирование с ноутбука в Wi-Fi – сеть нестабильна, результаты некорректны. Используйте проводное подключение или выделенные серверы.

2. Отсутствие мониторинга – тест показал 200 OK, но сервер уже на пределе CPU. Снимайте метрики с целевого сервиса параллельно.

3. Тест без прогрева – первые запросы всегда медленнее из-за JIT-компиляции и кэширования. Давайте системе 2-3 минуты на прогрев.

4. Один сценарий – в реальности пользователи делают разные действия. Смешивайте сценарии (чтение/запись в соотношении 80/20 или 70/30).

5. Игнорирование зависимостей – тестируете свой API, а он дергает сторонний сервис. Учитывайте время отклика внешних систем.

Заключение

Расчет нагрузки – это не формула один раз и навсегда. Это итеративный процесс: рассчитали параметры → провели тест → увидели узкое место → оптимизировали → пересчитали → повторили.

Начните с простого: определите пиковое количество пользователей, посчитайте ориентировочный RPS, запустите smoke test. Добавляйте сложность постепенно – переходите к распределенному тестированию, мониторингу и анализу процентилей только когда базовые тесты показывают стабильность.

Помните: плохой специалист смотрит на среднее время. Хороший – строит профиль нагрузки, находит узкое место и исправляет его до релиза, а не в 3 часа ночи.