Какие ключевые метрики используются в нагрузочном тестировании?

А, вот ты про нагрузку спрашиваешь! Ну, слушай, это ж как в спортзале: пока не начнёшь штангу ебашить — не поймёшь, где у тебя связки хрустят. Так и с системой. Чтобы не было потом "ой, всё упало", надо за ней, за сукой, следить по нескольким фронтам. Не просто ткнуть и побежать, а с умом.

1. Метрики производительности (Performance) — "Быстро ли она шевелит булками?"

• Время отклика (Response Time): Это самое главное. Не просто среднюю температуру по больнице смотреть, а вот эти перцентили — p95, p99. Потому что если для 95% пользователей всё летает, а для оставшихся 5% — пиздец как тормозит, то эти 5% тебе такой срач в ревью накидают, мало не покажется. И максимальное время — тоже, чтобы понять, в какой момент она совсем охренела.
• Пропускная способность (Throughput): Сколько запросов в секунду она может проглотить, не подавившись. RPS/TPS. Если этот показатель на графике похож на мёртвую крысу — плохо.
• Задержка (Latency): Чистое время обработки, без учёта того, как долго запрос по сети ползёт. Чтобы понять, тормозит само ядро или просто сеть — говно.

2. Метрики надёжности (Reliability) — "Или она просто сдохнет?"

• Процент ошибок (Error Rate): Сколько запросов кончились не "ОК", а каким-нибудь позорным "500 Internal Server Error" или "408 Timeout". Даже 0.5% — это уже повод задуматься, что там у неё внутри болит.
• Доступность (Availability): По сути, обратная величина к ошибкам. Сколько процентов времени она хоть что-то, да отвечала. Если ниже 99.9% — это уже не система, а мартышлюшка какая-то.

3. Метрики использования ресурсов (Resource Utilization) — "Во что ей наши потроха обходятся?"

• Использование ЦП (CPU Usage): Если процессор на сервере пыхтит на 98%, как паровоз перед инфарктом — это явный знак, что пора либо оптимизировать код, либо добавлять железа. Иначе он просто вскипит и накроется медным тазом.
• Использование памяти (Memory Usage): Чтобы память не кончилась раньше, чем тест. Утечки памяти — это тихий, ебаный убийца.
• Ввод-вывод диска и сети (Disk/Network I/O): Диск не должен скрипеть, как немазаная телега, а сетевая карта — не должна быть забита под завязку. Иначе всё упрётся в них, а не в логику.

4. Метрики масштабируемости (Scalability) — "А если народу придёт овердохуища?"

• Точка деградации (Breaking Point): Самый интересный момент! Та нагрузка, после которой график времени отклика перестаёт быть прямой линией и резко уходит вверх, как хуй с горы. Вот эту точку и ищем — чтобы знать, на какой мощности она начинает пиздец как тупить.
• Эффективность масштабирования: Добавили ещё два сервера — пропускная способность выросла в два раза? Отлично. Выросла всего на 20%? Значит, архитектура — говно, и бутылочное горлышко где-то в другом месте (чаще всего — база данных).

Пример отчёта (на основе вывода JMeter или Gatling): Вот, смотри, как это выглядит в жизни. Не просто цифры, а история:

Общее количество запросов: 10,000
Среднее время отклика: 245 мс (вроде норм, да?)
95-й перцентиль (p95): 520 мс (ого, а это уже не очень)
Максимальное время отклика: 1,850 мс (ёпта, а это кто и когда так ждал?!)
Пропускная способность: 412.3 запр./сек
Процент ошибок: 0.15% (ну, ладно, сойдёт, но копнуть надо)

Видишь? Средняя — 245 мс, а каждый двадцатый запрос (p95) — уже полсекунды. А кому-то и вовсе почти две секунды прилетело! Вот на эти выбросы и надо смотреть в первую очередь, ебать их в сраку. Потому что пользователь, который попал в эти 5% или в тот один запрос на 1.8 секунды, уже пишет гневный пост в твиттер. Вот и вся нагрузочная магия.