Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

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

5 <h2>Вариации графика</h2>

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

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

8 <h2>Распределение Response Time</h2>

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

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

11 <h2>Latency</h2>

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

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

14 <h2>Bandwidth</h2>

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

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

17 <p><em><a>Предыдущая часть статьи</a></em>.</p>