График Response Time и его вариации | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
C++ Developer. Professional JavaScript Developer. Professional Android Developer. Professional Microservice Architecture React.js Developer JavaScript Developer. Basic PostgreSQL Программист С C++ Developer. Basic Team Lead PHP Developer. Professional Подготовка к сертификации Oracle Java Programmer (OCAJP) Алгоритмы и структуры данных Разработчик IoT C# Developer. Basic Unreal Engine Technical Game Design C# ASP.NET Core разработчик Python Developer. Professional Python Developer. Basic Node.js Developer iOS Developer. Professional Cloud Solution Architecture Kotlin Backend Developer Agile Project Manager Scala-разработчик Symfony Framework iOS Developer. Basic Супер-интенсив Azure Специализация Python Developer
Инфраструктура
Экспресс-курс по управлению миграциями (DBVC) Экспресс-курс «IaC Ansible» Microservice Architecture Разработчик программных роботов (RPA) на базе UiPath и PIX Внедрение и работа в DevSecOps NoSQL Специализация Administrator Linux
-24%
Разработчик IoT Мониторинг и логирование: Zabbix, Prometheus, ELK MongoDB
-30%
DevOps практики и инструменты MS SQL Server Developer SRE практики и инструменты Administrator Linux. Advanced Infrastructure as a code Супер-интенсив "Tarantool" Специализация Network engineer
Корпоративные курсы
Экспресс-курс по управлению миграциями (DBVC) Экспресс-курс «IaC Ansible» Разработчик программных роботов (RPA) на базе UiPath и PIX Внедрение и работа в DevSecOps NoSQL Spark Developer Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» Game QA Engineer DevOps практики и инструменты Enterprise Architect Node.js Developer Cloud Solution Architecture Agile Project Manager Супер-практикум по работе с протоколом BGP Infrastructure as a code Промышленный ML на больших данных Супер-интенсив Azure Руководитель поддержки пользователей в IT
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02

График Response Time и его вариации

Чаще всего измеряется в миллисекундах — показывает время ответа на запросы к приложению. Время отклика не должно превышать SLA. Этот график является основным инструментом для поиска точек деградации при проведении нагрузочного тестирования.

Если на графике видны пики, значит, в этот момент приложение не отвечало по какой-то причине — это может являться отправной точкой для дальнейших исследований. Время отклика должно быть равномерным, без пиков для всех операций на протяжении всей ступени нагрузки, а также коррелировать с увлечением нагрузки. Gatling не содержит график «чистого» (среднего, неагрегированного) времени отклика, в отличие от других инструментов.

Кроме графика времени ответа каждого запроса, удобно показывать также линию с суммарным временем ответа (Total Response Time). Если наложить график подаваемой нагрузки (VU/RPS), можно отслеживать корреляцию с увеличением времени отклика от увеличения подаваемой нагрузки (VU/RPS). В Apache JMeter этот график называется Response Times vs Threads.

Далее пойдут графики, на которых может быть множество линий, каждая из которых отображает свой сценарий или запрос. Если у вас сложный тест со множеством операций и нелинейным профилем, советуем отражать в отчете лишь наиболее показательные запросы или группы запросов. Как вариант, можно отражать лишь запросы, превысившие SLA/SLO, чтобы не засорять график и отчет.

3-1801-9da559.png

Вариации графика

Возможна модификация, в которой применяются перцентили времени отклика и добавляется линия среднего времени отклика по всем запросам. Использование перцентилей здесь будет более правильным решением, так как среднее время отклика очень чувствительно к резким выбросам.

В тестировании производительности чаще всего используется 95 и 99 перцентиль для большей наглядности. Однако, если вы все же смотрите среднее время отклика, вам стоит учитывать при этом стандартное (среднеквадратичное) отклонение.

4-1801-bda6b6.png

Распределение Response Time

Также есть прекрасные графики, показывающие зависимость распределения времени от количества запросов.

Этот вид графиков чем-то напоминает индикаторы, но показывает более полную картину распределения времени, без обрезки перцентилями или другими агрегатами. С помощью графика можно более наглядно определить границы для групп индикаторов. У MF LoadRunner такого графика нет.

5-1801-15a7b2.png

Latency

Из этой метрики также можно выделить дополнительный параметр Latency (миллисекунды) — время задержки (чаще всего под этим понимают Network Latency). Этот параметр показывает время между окончанием отправки запроса до получения первого ответного пакета от системы.

С помощью этого параметра можно измерять также задержки на сетевом уровне, если параметр будет расти. Желательно, чтобы он стремился к нулю. Этот тип графиков в основном используются при глубоком анализе и поиске проблем производительности. Этого графика из коробки нет в Gatling. В MF LoadRunner этот график называется Average Latency Graph в блоке Network Virtualization Graphs, если у вас установленные агенты мониторинга.

6-1801-a807ff.png

Bandwidth

Аналогично метрике выше можно выделить параметр Bandwidth (килобит в секунду) — ширину пропускания канала. Он показывает, какой максимальный объем данных может быть передан за единицу времени.

Изменяя этот параметр на инструменте нагрузки, можно моделировать различные источники подключений к приложению: мобильная связь 4G или проводная сеть. В бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Этот график из коробки есть лишь в MF LoadRunner, находится в том же блоке, что и Latency, и называется Average Bandwidth Utilization Graph.

Предыдущая часть статьи.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться