Профилирование под нагрузкой

Тема дорожной карты · QA-инженер

Профилирование производительности — это процесс инструментирования работающего приложения для сбора детальных данных о загрузке CPU, выделении памяти, конкуренции потоков и операциях ввода-вывода, чтобы QA-инженеры и разработчики могли выявить первопричину замедлений, обнаруженных в ходе нагрузочных тестов. Инструменты профилирования, такие как VisualVM, async-profiler, py-spy и встроенный Java Management Agent, подключаются к работающей JVM или Python-процессу и создают флейм-графы, отображающие горячие пути кода без необходимости изменений исходного кода. Профилирование производительности обычно применяется после того, как стресс-тесты JMeter или k6 выявляют узкое место — профайлер затем сужает расследование от симптома на уровне сервиса (высокая задержка p99) до конкретного метода, SQL-запроса или системного вызова. Непрерывное профилирование производительности, интегрированное в CI/CD-пайплайны через тестовые среды на основе Docker, помогает командам обнаруживать регрессии до попадания в продакшен.

Как это работает

Профилирование под нагрузкой валидирует поведение системы под нагрузкой. Инструменты: k6 (современный, на JavaScript, рекомендуется), JMeter (legacy, Java, GUI), Locust (Python, скриптуемый), Gatling (Scala, code-first), Artillery (Node). Типы: load (ожидаемый трафик, sustained), stress (за пределами ожидаемого — точка слома), spike (внезапный всплеск), soak (многочасовая выдержка — ловит утечки), capacity (максимум sustainable). Метрики: throughput (req/s), latency (p50, p95, p99), error rate.

Когда применять

Гоняйте perf-тесты до запуска (find capacity), до major-релизов (regression), после изменений архитектуры. Тестируйте против production-shaped среды — не "ноут с моками". Всегда меряйте p95/p99 latency, не только average (average прячут outliers). Распределённую load-generation — если трафик > одной машины. SLO сначала; perf-тесты их верифицируют.

Типичные ошибки

Ловушки Профилирование под нагрузкой: load-тестируете свой ноут вместо целевой среды (результаты бесполезны); не прогрели систему до замеров (cold-cache цифры неверны); load генерируется из той же сети, что и target (меряете локальную сеть, не систему); не тестируете think-time (реальные юзеры не долбят refresh постоянно).

Связанные понятия

Полезные ресурсы