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

Введение: Проверка на прочность

Представьте, что вы построили мост. Архитекторы проверили чертежи. Строители проверили каждый болт и каждую сварку. Но вы не знаете, выдержит ли мост 10 машин одновременно. Или 100. Или 1000.

Нагрузочное тестирование — это проверка моста на прочность. В мире API это проверка того, как система ведёт себя под нагрузкой: сколько запросов в секунду выдерживает, как быстро отвечает, не падает ли, когда становится тяжело.

Нагрузочное тестирование (Load Testing) — это тестирование производительности системы под ожидаемой нагрузкой. Оно отвечает на вопросы: “Сколько пользователей может обслуживать API?”, “Какое время ответа?”, “Где узкое место?”.

Для системного аналитика нагрузочное тестирование — это проверка нефункциональных требований. Вы не проверяете, правильно ли API считает скидку (это модульные тесты). Вы проверяете, что API отвечает за 200 мс при 1000 запросах в секунду.

Виды нагрузочного тестирования

Ключевые метрики

Время отклика (Latency)

Что важно понимать: Среднее арифметическое (mean) часто обманчиво. Медиана (p50) даёт лучшее представление о типичном пользователе.

Пропускная способность (Throughput)

Потребление ресурсов

Процент ошибок

Процесс нагрузочного тестирования

Этапы

    graph LR
    A[Планирование] --> B[Создание сценариев]
    B --> C[Запуск тестов]
    C --> D[Сбор метрик]
    D --> E[Анализ]
    E --> F[Оптимизация]
    F --> B
  

Что делает аналитик на каждом этапе

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

Популярные инструменты

Что важно для аналитика

Сценарии нагрузки

Постепенное увеличение (Ramp-up)

Нагрузка растёт постепенно от 0 до целевого значения.

Время (сек): 0 → 60 → 120
RPS:        0 → 500 → 1000

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

Постоянная нагрузка (Constant)

Фиксированное количество RPS в течение времени.

Время (сек): 0 → 300 → 600
RPS:        1000 → 1000 → 1000

Что даёт: Проверка стабильности под нагрузкой.

Пиковая нагрузка (Spike)

Внезапный резкий скачок нагрузки.

Время (сек): 0 → 10 → 60
RPS:        100 → 5000 → 100

Что даёт: Проверка, не падает ли система при резком скачке.

Нагрузка до разрушения (Stress)

Нагрузка увеличивается, пока система не начнёт падать.

Время (сек): 0 → 300 → ...
RPS:        100 → 200 → 400 → 800 → 1600 → (падение)

Что даёт: Понимание предела прочности.

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

Хорошие результаты

Тревожные сигналы

Типичные узкие места

Пример: Отчёт нагрузочного тестирования

Шапка

Отчёт нагрузочного тестирования
API: GET /users/{id}
Дата: 2024-01-15
Цель: 1000 RPS, p95 < 200 мс
Инструмент: k6

Результаты

График

Время отклика (мс)
500 |                          *
400 |                        * *
300 |                      * * *
200 |    * * * * * * * * * * * * *
100 |  * * * * * * * * * * * * * * *
  0 +--------------------------------
    0   100  200  300  400  500  600  RPS

Выводы

1. Целевая нагрузка 1000 RPS достигнута.
2. p99 превышает цель (320 мс > 300 мс) при нагрузке > 800 RPS.
3. Рекомендация: оптимизировать медленные запросы, добавить кеш.

Нагрузочное тестирование в CI/CD

Где запускается

    graph LR
    A[Модульные тесты] --> B[Интеграционные]
    B --> C[Нагрузочные]
    C -->|Ночной запуск| D[Отчёт утром]
  

Особенности запуска

Интеграция с CI

# Пример .gitlab-ci.yml
load_test:
  stage: test
  script:
    - k6 run load_test.js
  artifacts:
    reports:
      load_report: load_report.json
  only:
    - main
  when: manual

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

Ошибка 1: Тестирование на неправильных данных

Тесты используют одни и те же данные, кеш разогрет, БД не напрягается.

Решение: Использовать разные данные (параметризация).

Ошибка 2: Тестирование на неправильной среде

Среда отличается от production: меньше ресурсов, другая конфигурация.

Решение: Стенд для нагрузочного тестирования должен быть как production.

Ошибка 3: Игнорирование холодного старта

Первый запрос после запуска может быть медленным из-за инициализации.

Решение: Игнорировать первые N запросов или сделать прогревочный прогон.

Ошибка 4: Смотреть только среднее

Среднее может быть хорошим, а p99 — ужасным.

Решение: Смотреть на перцентили (p95, p99).

Ошибка 5: Тестирование одного эндпоинта

В реальности пользователи делают разные запросы.

Решение: Смешанный сценарий: 60% GET /users, 20% GET /orders, 10% POST /orders, 10% остальное.

Планирование нагрузочного тестирования

Вопросы для аналитика

Пример целевых показателей (SLO)

Резюме

1. Нагрузочное тестирование — проверка производительности системы под нагрузкой. Ответы на вопросы: “Сколько выдержит?”, “Как быстро?”, “Где узкое место?”

2. Виды: Load (ожидаемая нагрузка), Stress (до разрушения), Soak (длительная), Spike (резкий скачок).

3. Ключевые метрики: время отклика (p50, p95, p99), пропускная способность (RPS), потребление ресурсов (CPU, RAM), процент ошибок.

4. Инструменты: k6 (современный, простой), JMeter (классика), Locust (гибкий).

5. Сценарии: постепенное увеличение, постоянная нагрузка, пик, нагрузка до разрушения.

6. Анализ: искать узкие места (БД, сеть, приложение, кеш). Смотреть на перцентили, не на среднее.

7. В CI/CD: нагрузочные тесты обычно запускаются ночью, не на каждый коммит. Нужен стенд, похожий на production.