Как читаешь результаты нагрузки
Вопрос
Как ты анализируешь результаты нагрузочного теста и что пишешь в отчёте?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Смотрю перцентили и ошибки во времени по ступеням нагрузки, а не средние за весь тест
Ищу точку, где время растёт нелинейно или растут ошибки: это предел
Сопоставляю с метриками ресурсов: CPU, память, пулы, база, очереди, GC
Проверяю достоверность: генератор не перегружен, ошибки не из-за скрипта, стенд соответствует
Отчёт: цель, профиль, стенд, результаты против критериев, узкие места, рекомендации
Что могут спросить следом
- Почему нельзя усреднять перцентили с разных агентов?
- Что такое coordinated omission?
- Как связаны RPS, время ответа и число пользователей?
Разбор
Я смотрю не на итоговые средние, а на графики во времени по ступеням нагрузки: RPS, p95 и p99, доля ошибок. Предел виден как точка, после которой RPS перестаёт расти, а время ответа уходит вверх нелинейно или начинаются ошибки. Дальше сопоставляю это с ресурсами: если CPU приложения упёрся, это одно, если CPU спокоен, а ответы растут, ищу ожидание: пул соединений к базе, блокировки, медленные запросы, внешние вызовы. Отдельно проверяю, можно ли верить цифрам: генератор не перегружен, ошибки настоящие, а не из-за протухших тестовых данных, перцентили посчитаны по объединённым данным, а не усреднены. Знаю про coordinated omission: если генератор ждёт ответа перед следующим запросом, медленные периоды недопредставлены, поэтому для честных хвостов нужна открытая модель. В отчёте: цель, профиль, стенд и его отличия от прода, результаты против критериев, найденные узкие места и рекомендации с приоритетом.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.