Как проверить производительность приложения?
Что проверяют
Есть ли у вас процесс, а не список инструментов: откуда берутся цели, какую нагрузку подавать, что мерить и как найти узкое место. Следом обычно спрашивают, чем нагрузочное тестирование отличается от стрессового и какие метрики попадут в отчёт.
Как отвечать
Начните с целей. Без требований вида «p95 поиска не больше 800 мс при 300 RPS» тест превращается в измерение ради измерения. Если требований нет, снимите базовую линию и договоритесь о порогах с командой.
Потом назовите виды тестов:
- нагрузочный: ожидаемая и пиковая нагрузка, проверка соответствия целям;
- стрессовый: нагрузку повышают до отказа, чтобы найти предел и посмотреть, как система деградирует и восстанавливается;
- пиковый (spike): резкий скачок, например после рассылки;
- длительный (soak): несколько часов под обычной нагрузкой, ловит утечки памяти и исчерпание пулов соединений.
Профиль нагрузки строится из реальной статистики: какие операции, в каком соотношении, с какими данными. Инструменты: JMeter, Gatling (сценарии на Java, Kotlin или Scala), k6 на JavaScript, Locust на Python. Во время прогона смотрят метрики сервера в Grafana и Prometheus или в APM: CPU, память, сборку мусора, пулы соединений, медленные запросы к базе.
В отчёт идут перцентили времени ответа (p50, p95, p99), пропускная способность, доля ошибок и потребление ресурсов, плюс вывод, где узкое место. После исправления тот же сценарий прогоняется снова и сравнивается с базовой линией.
Если речь о клиентском приложении, добавьте его сторону: Lighthouse для веба, профилировщики Android Studio и Xcode Instruments для мобильных.
Где спотыкаются
Начинают с выбора инструмента, не определив цели и профиль нагрузки.
Гоняют тест на окружении, которое на порядок слабее прода, или на пустой базе, а цифры переносят на прод как есть.
Путают генератор нагрузки с узким местом: машина с JMeter упирается в свой CPU, и растущее время ответа меряет её, а не приложение.