Нагрузочное и стресс-тестирование
1) Термины и цели
Load test — проверка в рабочем диапазоне (target RPS/конкурентность) против SLO (например, p95 < 200 мс, error rate < 0.5%).
Stress test — выход за пределы (до/сверх насыщения CPU/БД/сети), наблюдение деградации и механики восстановления.
Spike test — резкие всплески нагрузки (×N в течение минут).
Soak/Endurance — длительный прогон (часы/сутки) для поиска утечек, дрейфа GC, фрагментации, ростов очередей.
Capacity test — вычисление плато пропускной способности (saturation point) и запасов.
Цели: подтвердить SLO, зафиксировать плато, понять узкие места, откалибровать авто-масштабирование и лимиты.
2) Модель трафика: открытая vs закрытая
Закрытая модель (concurrency-driven): фиксированное число виртуальных пользователей (VUs), каждый после ответа делает think time.
Открытая модель (arrival-rate): фиксированная интенсивность поступления запросов (RPS), независимо от ответов.
Little’s Law: `L = λ W`
`L` — среднее число одновременно обслуживаемых запросов,
`λ` — интенсивность (RPS),
`W` — среднее время ответа.
Отсюда оценка нужной конкурентности генератора: `concurrency ≈ target_RPS p95_latency`.
3) Метрики: что измеряем
SLI задержек: p50/p90/p95/p99 и хвост p99.9; отдельные для «горячих» и «холодных» путей.
Ошибки: `5xx`, `4xx` (валидные/невалидные), timeouts, aborted.
Пропускная способность: устойчивый RPS, throughput потоков/байт.
Ресурсы: CPU, RAM/heap, GC-паузы, дисковая IOPS/lat, сетевой bandwidth, количество соединений/FD.
Очереди и бэкпрешер: глубина, время ожидания, количество shed/limited запросов.
Эффективность кэша: hit/miss, штормы прогрева.
БД/кэши/очереди: p95 запросов, блокировки, конфликты, pool utilization.
4) Стенды и данные
Конфигурационная эквивалентность: версии софта, лимиты (uLimit, conntrack), конфиговка JVM/GC, pool’ы.
Топология: LBs, CDN, WAF, TLS, те же сетевые «хопы».
Данные: реалистичные распределения (размеры объектов, «горячие»/«холодные» ключи, региональность).
Холодный/теплый/горячий старт: отдельные прогоны; обязательно тестировать «холодные» кэши.
Изоляция фона: отключить нерелевантные джобы/крономы или учесть их эффект.
5) Сценарии (профили нагрузки)
1. Baseline: ступенчатый разгон до целевого RPS, удержание 10–30 мин.
2. Ramp & Hold: плавный рост до X% выше цели, удержание → анализ хвостов.
3. Spike: мгновенный ×2–×5 всплеск на 1–5 мин, затем возврат.
4. Stress to Failure: ступенями до отказов; фиксируем первую точку невыполнения SLO и точку «ломки».
5. Soak: 6–24 ч с вариативностью трафика (день/ночь), следим за ликами/дрейфом.
6. Mixed: смесь эндпоинтов по реальному распределению (Zipf/pareto), разные веса.
6) Пошаговый процесс
Определить SLO и целевые профили трафика.
Выбрать модель нагрузки (открытая/закрытая), задать arrival-rate или VUs.
Подготовить данные и «горячие»/«холодные» режимы.
Настроить телеметрию (трейсы/метрики/логи), корелляцию с тест-раном.
Разогрев и прогон, сбор артефактов (профили CPU/heap, flame graphs, explain/slow-logs БД).
Анализ узких мест, формирование action items.
Репрогон после фиксов, обновление базлайна и capacity playbook.
7) Узкие места и типичные фиксы
CPU-bound сервис: профилирование → устранение горячих функций, аллокаций, ветвлений; векторизация, кэш-friendly структуры.
Сеть/TLS: keep-alive, HTTP/2/3, connection pooling, правильные таймауты, уменьшение чатовости.
БД: индексы, батчинги, подготовленные запросы, пул коннектов, R/W-разделение, кэширование результатов, дедупликация запросов.
Кэши: размер, TTL, request coalescing, защита от штормов, warming, региональные шары.
Очереди/брокеры: лимиты приятием/параллелизм, размер батчей, idempotent consumers, DLQ-потолки.
Гарбатедж/паузы: тюнинг GC, аренда буферов, object pooling в разумных пределах.
I/O/диск: асинхронный ввод/вывод, компрессия, сжатие ответов с разумным уровнем.
8) Лимиты и защита
Budget таймаутов: сверху вниз, чтобы избежать каскадов.
Rate limit / токен-бакеты: предсказуемая деградация вместо «долгой смерти».
Сircuit breaker и шейдинг низкого приоритета при насыщении.
Backpressure: сигналы и ограничение параллелизма вглубь цепочки.
Bulkheads: изоляция пулов под критичные эндпоинты.
Idempotency: ключи для безопасных повторов под ретраями.
9) Инструменты и когда их выбирать
k6 — лаконичный JS, отличная поддержка arrival-rate, интеграции и графы.
Gatling — Scala DSL, высокопроизводительный генератор.
JMeter — гибкий, богатый экосистемой; удобен для протоколов/плагинов.
Locust — Python-сценарии, удобно для сложной логики пользовательских флоу.
Vegeta/hey/wrk — микробенчи и точечные прогоны на HTTP.
tc/netem, toxiproxy — инъекция сетевых деградаций.
Flamegraph/profiler — поиск «горячих мест» CPU/heap.
10) Примеры (скетчи)
k6 (открытая модель, mix эндпоинтов)
javascript import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};
export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}Gatling (ступени и спайк)
scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))Нагрузочный план (YAML-скелет)
yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m11) Автоматизация и жизненный цикл
Perf-smoke в каждом PR (короткий прогон ключевых эндпоинтов).
Ночные «capacity» прогоны на стейдже с отчетами и артефактами профилей.
Гейты в CI/CD: фэйл билда при регрессе p95/p99 > X% от базлайна или росте error rate.
Версионирование базлайнов и хранение профилей/флеймграфов как артефактов.
Теги релевантности: какой сервис/эндпоинт покрыт, какой профиль трафика использован.
12) Анти-паттерны
Генератор и тестируемый сервис на одной машине → искаженные результаты.
Только закрытая модель (VUs) для API-бэков → занижение хвостов и неверная оценка.
Прогоны по пустой БД/кэшу без холодного старта.
Отсутствие реалистичных распределений (все запросы одинаковые).
Нет телеметрии (только RPS/latency со стороны генератора).
Сравнение без стабильных базлайнов и контроля среды.
«Оптимизация» через увеличенный таймаут вместо исправления причины.
13) Чек-лист архитектора
1. Определены SLO и типовая/пиковая нагрузка?
2. Выбрана корректная модель (open/closed) и расписан профиль трафика?
3. Стенд эквивалентен по конфигам и топологии, есть холодный/горячий режим?
4. Телеметрия и профили включены, метки тест-рана проставляются?
5. Прогоны: baseline / ramp / spike / stress / soak — покрыты?
6. Фиксируются точки насыщения и планируется запас (safety margin)?
7. Настроены лимиты, брейкеры, бэкпрешер, idempotency, полисы шейдинга?
8. Есть CI-гейты на регресс p95/p99 и error rate, базлайны версионированы?
9. После фиксов — репрогон и обновление playbook по мощности?
10. Документирован план авто-масштабирования и аварийных режимов?
Заключение
Нагрузочное и стресс-тестирование — это не разовые «гонки», а непрерывная инженерная практика. Реалистичная модель трафика, корректные стенды, телеметрия и автоматизация в CI/CD превращают производительность из «тайной магии» в управляемую метриками способность: вы знаете, где ваш потолок, насколько безопасен запас и какие изменения реально улучшают опыт пользователей.