четверг, 10 декабря 2009 г.

Метрики времени отклика - необходимы но недостаточны для анализа результатов

Я несколько раз видел ситуации, когда инженеры делали оценку результата тестирования производительности по табличным данным. Типичный пример - разработчик или тестировщик, которые выполняют тест используя jmeter. Поскольку в jmeter нет нормального графического представления трендов транзакций, графами результатов никто не пользуется(не без исключений). Второй момент это то, что графы сами по себе не очень то информативны но если они есть их нужно использовать и я объясню почему.

Я хочу показать каким важным элементом для полноценного анализа результатов тестирования производительности есть их визуализация. Визуализация в данном случае это представление трендов транзакций в графической форме, так называемые transactions graphs.

Не секрет, что основными метриками оценки производительности программных систем есть метрики времени отклика(response time metrics). Время отклика (response time)- это продолжительность времени между моментом, когда пользователь подал запрос на доступ к данным и возвратом данных пользователю.

Если вы когда-либо работали с Jmeter вы, наверное, использовали listener "Summary report" (элемент табличного вида для отображения результатов в реальном времени). Недостатком этого элемента является то, что в нем скудный набор метрик времени отклика(в jmeter это elapsed time, которое отличается от классического определения времени отклика).
Summary report представляет следующие метрики времени отклика: average сокращенно avg( среднее арифметическое всех значений полученных при прогоне теста), min(наименьшее значение), max(наибольшее значение), std. dev.(cреднеквадратическое отклонение). Очевидно, что с таким набором метрик анализировать результаты крайне сложно так же как и делать выводы. Если не учитывать min и max с которых толку не много у вас есть только две метрики для анализа avg и std. dev. Из самого определения avg, очевидно, что метрика при определенных обстоятельствах может иметь большую погрешность. "Cудить" о результатах прогона теста используя только avg крайне не желательно.

Также в jmeter есть другой listener "Aggregate report" в котором добавлены метрики median и 90%Line, но нету std. dev(в целях экономии ресурсов).

Median - число, которое делит ряд возрастающих (или убывающих) значений на две части, равные по числу значений. Попросту говоря, если у вас после прогона теста median равен X значит 50% ваших значений меньше X, а другие 50% больше X. Еще одно определение, которое, как по мне, более понятнее: median - это середина(число) упорядоченного массива полученных значений по возрастанию или по убыванию.

90%Line(90th Percentile) - число(значение) которое делит ряд возрастающих значений на две части: 90% значений меньше этого числа, оставшиеся 10% или равны этому числу или больше.

Теоретически имея median и 90%Line и остальные метрики мы можем довольно точно оценить состояние системы. На практике это не всегда так.

Допустим мы используем "Aggregate report" и прогнали 5 часовой тест. За это время было снято 1000 значений времени отклика для одной из транзакций, например, "Поиск товара". На протяжении всего теста время отклика транзакции "Поиск товара" было в норме, скажем ~5 секунд при требуемых 7 секундах. Однако, в последние 20 минут теста время отклика для транзакции "Поиск товара" значительно увеличилось до 20 секунд, что потенциально может указывать на то, что система вошла в такое состояние, когда какая-то ее часть становится узким местом.

Несложно посчитать что за 20 минут было снято 66 неприемлемых значений.
Что покажут метрики Agrregate report в данном случае? Для простоты вычислений допустим, что время отклика до деградации было постоянным числом и составляло 5 секунд, итого получаем:
Average - 5,99 сек - среднее арифметическое всех значений, проблема деградации невидна
Median - 5 сек - проблема деградации невидна
90% Line - несмотря на, казалось бы, большую информативность этой метрики в этом случае она даже менее точна чем avg. Поскольку 90%Line в массиве из 1000 значений это 900ое значение. Если мы упорядочим 1000 значений по возрастанию, очевидно, что ни одно из 66 неприемлемых значений не может быть 900м, все они находятся в конце массива. Имеем в результате 90%Line равным 5 секундам.
Min - 5 секунд
Max - 25 секунд

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

Комментариев нет:

Отправка комментария