Многим тестировщикам хорошо известны такие инструменты, как JMeter, Gatling, Tsung и т.д. Хотя они довольно просты в использовании, анализ полученных результатов и выводы на их основании представляют для них некоторую сложность. Во время проведения собеседований на позицию QA инженера часто встречаются кандидаты, утверждающие, что у них есть опыт в области тестирования производительности, но, по факту, не обладающие знаниями метрик и основных понятий, с ним связанных. Поскольку основной задачей тестирования производительности является не знание инструментария, а данные, полученные с его помощью, цель этого материала - рассмотреть основные аспекты этой сферы тестирования.
Одно из основных заблуждений заключается в смешивании понятий тестирования производительности и нагрузочного тестирования. Оба эти термина зачастую используются как синонимы, но совершенно точно это - разные понятия.
Цель тестирования производительности - выявить “узкие места” в системе или архитектуре. Существует выражение, что наша система является настолько быстрой, насколько быстр наш самый медленный сервис. Представим, что система состоит из различных микросервисов. У каждого существует свое время ответа или расчетная (предполагаемая) нагрузка. В таком уравнении существует даже больше переменных как, например, тип базы данных, серверов или местоположение центра обработки данных.
Пользователям приложения нужны две вещи: быстрое время ответа и высокая отказоустойчивость.
С помощью тестирования производительности мы можем выявлять эти узкие места в архитектуре и масштабировать, конфигурировать и регулировать сервисы независимо для достижения такого быстродействия конечными пользователями.
А что насчет высокой отказоустойчивости? Эта характеристика как раз на стороне нагрузочного тестирования. Проще говоря, нагрузочное тестирование - это проверка нашей системы с помощью огромного количества одновременных пользователей или подключений, которые и являются нашей нагрузкой. Это количество мы постоянно увеличиваем для достижения максимального количества задач, с которыми система может справиться. Нагрузочное испытание наиболее актуально при релизе нового сервиса, когда нужно проверить, выдержит ли он ожидаемый поток трафика. Цель этого испытания - проверка работоспособности всей системы, а не производительность отдельных её сервисов.
И хотя методы проведения нагрузочного тестирования и тестирования производительности кажутся схожими с точки зрения инструментария и техник, различия становятся более явными при анализе результатов и определении способов реагирования.
Как уже было указано выше, определяющую роль в нагрузочном тестировании и тестировании производительности играет анализ результатов. Чтобы его сделать, необходимо знать основные метрики производительности. В особенности в мире сетевого взаимодействия, очень важно снимать метрики времени задержки, пропускной способности и ширины пропускания канала:
- Время задержки (Latency) - временной интервал между запросом и ответом. Например, у вашего сервиса время задержки составляет 100ms, что означает, что такому сервису потребуется 100 миллисекунд на обработку запроса и генерирование ответа. Как правило, чем ниже время задержки, тем лучше клиентский опыт.
- Пропускная способность (Throughput) - фактическое количество запросов (или пользователей), которое может обработать система за определенное время. В то время как время задержки говорит вам только о времени, метрика пропускной способности информирует об объеме данных, полученных и обработанных в момент времени. Важно не отделять показатели времени задержки от пропускной способности, т.к. высокий показатель времени задержки часто прямо связан с увеличением показателей метрики пропускной способности. Пропускная способность обычно измеряется в rps – (кол-во) запросов в секунду (requests per second).
- Ширина пропускания канала (Bandwidth) - максимальное число запросов (или пользователей), которое может обработать система. В отличие от пропускной способности ширина пропускания канала измеряет максимальный объем, который может обработать приложение. В то время как ширина пропускания канала, как правило, величина постоянная (в определенный период времени), очень важно производить анализ метрик времени задержки и пропускной способности параллельно, т.к., основываясь на них, можно сделать заключение о производительности вашего приложения.
После измерения времени задержки, одним из use-кейсов, который приходит на ум, является подсчет среднего времени задержки в определенный отрезок времени. Первые статистические данные, которые кажутся необходимыми для расчета - это расчет средне-арифметического значения. Однако, сложность состоит в том, что средне-арифметическое значение очень чувствительно к большим отклонениям. Поскольку схема времени задержки выглядит довольно равномерной с несколькими заметными всплесками, процентили являются более подходящей статистической единицей в этом случае. Если вам нужно измерить среднее время задержки сервиса, вы можете использовать медиану, которая является 50-м процентилем (p50). Но помните, что p50 также очень чувствительна к статистическим колебаниям. Наиболее используемыми величинами для измерения среднего времени ответа являются 90-й и 99-й процентили (p90 и p99). Например, если время задержки для p90 составляет 1ms, это означает, что в 90% случаев ваш сервис отвечает по истечению 1ms.
При измерении показателя пропускной способности мы получаем величину объема трафика, который обрабатывается сервисом, но что можно сказать об ответах? Коды ответов сервиса (2xx, 4xx или 5xx) имеют существенное значение. По ним определяется частота появления ошибок. Цель мониторинга частоты появления ошибок - определить, какое количество (или процент) ответов сервиса составляют положительные ответы и т.п. Всегда есть доля ответов с ошибками (в том числе связанных с валидацией на клиенте - 4xx код). И если мы замечаем внезапные всплески на диаграмме частоты появления ошибок, это может говорить о неполадках сервиса.
Для эффективной отладки и масштабирования системы нужно в первую очередь понимать, что же необходимо измерить (а как - это вторично).