AS
Привет всем!
Есть вопрос, буду благодарен за помощь.
Я заметил, что в моей панельке в графана неправильно выводятся percentiles и average response time, сравнивал я с агрегейт репортом в jmeter и html репортом.
У меня значения этих метрик отличаются в графана и агрегейт репорте / html репорте, моя query в influx:
SELECT
sum ( "count") as NumberOfSamples,
min (min) as Min,
max (max) as Max,
last (avg) as Average,
last ( "pct90.0") as Percentile90,
last ( "pct95.0") as Percentile95,
last ( "pct99.0") as Percentile99
FROM jmeter
WHERE "statut" = 'ok'
AND $timeFilter
AND transaction! ~ / (Setup) /
AND ( "application" = ~ / ^$application$ /)
GROUP BY "transaction"
Также я еще пробовал писать так:
percentile ( "pct90.0", 90) as "Percentile 90",
percentile ( "pct95.0", 95) as "Percentile 95",
percentile ( "pct99.0", 99) as "Percentile 99"
Значение percentiles конечно меняется, но оно все равно не совпадает с тем, что я вижу в агрегейт репорте, или в html репорте.
Также я пробовал раскомментировать в jmeter.properties такие строки(font-bold), но это не помогло:
# BackendListener - configuration
#---------------------------------------------------------------------------
#
# Backend metrics window mode (fixed=fixed-size window, timed=time boxed)
backend_metrics_window_mode=timed
# Backend metrics sliding window size for Percentiles, Min, Max
backend_metrics_window=50000
# Backend metrics sliding window size for Percentiles, Min, Max
# when backend_metrics_window_mode is timed
# Setting this value too high can lead to OOM
backend_metrics_large_window=50000
Кто нибудь сталкивался с такой проблемой?
Есть вопрос, буду благодарен за помощь.
Я заметил, что в моей панельке в графана неправильно выводятся percentiles и average response time, сравнивал я с агрегейт репортом в jmeter и html репортом.
У меня значения этих метрик отличаются в графана и агрегейт репорте / html репорте, моя query в influx:
SELECT
sum ( "count") as NumberOfSamples,
min (min) as Min,
max (max) as Max,
last (avg) as Average,
last ( "pct90.0") as Percentile90,
last ( "pct95.0") as Percentile95,
last ( "pct99.0") as Percentile99
FROM jmeter
WHERE "statut" = 'ok'
AND $timeFilter
AND transaction! ~ / (Setup) /
AND ( "application" = ~ / ^$application$ /)
GROUP BY "transaction"
Также я еще пробовал писать так:
percentile ( "pct90.0", 90) as "Percentile 90",
percentile ( "pct95.0", 95) as "Percentile 95",
percentile ( "pct99.0", 99) as "Percentile 99"
Значение percentiles конечно меняется, но оно все равно не совпадает с тем, что я вижу в агрегейт репорте, или в html репорте.
Также я пробовал раскомментировать в jmeter.properties такие строки(font-bold), но это не помогло:
# BackendListener - configuration
#---------------------------------------------------------------------------
#
# Backend metrics window mode (fixed=fixed-size window, timed=time boxed)
backend_metrics_window_mode=timed
# Backend metrics sliding window size for Percentiles, Min, Max
backend_metrics_window=50000
# Backend metrics sliding window size for Percentiles, Min, Max
# when backend_metrics_window_mode is timed
# Setting this value too high can lead to OOM
backend_metrics_large_window=50000
Кто нибудь сталкивался с такой проблемой?
154
154
152
152
151
150
150
150
149
147
147
Джиметр агрегейт репорт показывает 90%=147ms,95%=151ms,99%=154ms, что вроде как правильно:
155
154 - 99% 1%, или в нашем случае просто 1 семпл лежит выше в отсортированом списке респонс таймов
154
152
152
151 - 95% 5%, или в нашем случае просто 5 семплов лежат выше в отсортированом списке респонс таймов
150
150
150
149
147 - 90%. 10%, или в нашем случае просто 10 семплов лежат выше в отсортированом списке респонс таймов
147
Но что показывает инфлюкс?
Запрос такой select "pct90.0","pct95.0","pct99.0",transaction,statut from jmeter where application='20' and statut='all' and transaction='jp@gc - Dummy Sampler'
И мы видим что ЗРАДА, последнее значение 90 персентиля 148.8, но никак не 147 как в джиметре, то же самое и для других персентилей.
name: jmeter
time pct90.0 pct95.0 pct99.0 transaction statut
---- ------- ------- ------- ----------- ------
1616507446817000000 151.70000000000002 153.9 154 jp@gc - Dummy Sampler all
1616507451817000000 148.7 151.89999999999998 154 jp@gc - Dummy Sampler all
1616507456814000000 145 149.95 154 jp@gc - Dummy Sampler all
1616507461816000000 148.70000000000002 151.95 155 jp@gc - Dummy Sampler all
1616507466817000000 148.8 151.95 154.99 jp@gc - Dummy Sampler all
Что же произошло? Ответ кроется в том как DescriptiveStatistics считает персентили. Они юзают следующий алгоритм
http://www.itl.nist.gov/div898/handbook/prc/section2/prc252.htm
The pth percentile is a value, Y(p), such that at
most (100p)% of the measurements are less than this
value and at most 100(1 - p)% are greater. The 50th
percentile is called the median.
Percentiles split a set of ordered data into
hundredths. For example, 70% of the data should fall
below the 70th percentile.
Note the use of "at most," which is necessary in order to make the definition work. In particular, the lowest and highest values are the 0th and 100th percentiles.
It does NOT say that 100% of the values are LESS than the 100th percentile; the "should" in the last sentence above is a general statement, not the actual definition.
То есть их логика немного отличается от того как считает джиметр. Джиметр берет в качестве персентиля конкретное значение респонс тайма семпла, а DescriptiveStatistics считает свое значение. И, к примеру, значение 90% должно быть такое что остальные 10% респонс таймов должны быть больше, НО само значение персентиля не будет одним из списка.
Теперь давайте проверим:
155
154
154
152
152
151
150
150
150
149
148.8 - 90% influxdb. Действительно, значение немного отличается, но это всеравно правильный и валидный 90 персентиль
147 - 90% jmeter 10%, или в нашем случае просто 10 семплов лежат выше в отсортированом списке респонс таймов
147
Так что подсумируя еще раз:
- в jmeter.properties меняем
backend_metrics_window_mode=timed
backend_metrics_window=50000(или другое большое число, больше чем количество семплов за тест)
backend_metrics_large_window=50000(или другое большое число, больше чем количество семплов за тест)
- в графане в панельках, где вы трекаете тренды юзаете avg, так как оно станет показывать значение за 5 сек
- в графане в таблицах считаете персентили через last("pct90.0"), а среднее через mean("avg")
и будет вам счастье 🙂
154
152
152
151
150
150
150
149
147
147
Джиметр агрегейт репорт показывает 90%=147ms,95%=151ms,99%=154ms, что вроде как правильно:
155
154 - 99% 1%, или в нашем случае просто 1 семпл лежит выше в отсортированом списке респонс таймов
154
152
152
151 - 95% 5%, или в нашем случае просто 5 семплов лежат выше в отсортированом списке респонс таймов
150
150
150
149
147 - 90%. 10%, или в нашем случае просто 10 семплов лежат выше в отсортированом списке респонс таймов
147
Но что показывает инфлюкс?
Запрос такой select "pct90.0","pct95.0","pct99.0",transaction,statut from jmeter where application='20' and statut='all' and transaction='jp@gc - Dummy Sampler'
И мы видим что ЗРАДА, последнее значение 90 персентиля 148.8, но никак не 147 как в джиметре, то же самое и для других персентилей.
name: jmeter
time pct90.0 pct95.0 pct99.0 transaction statut
---- ------- ------- ------- ----------- ------
1616507446817000000 151.70000000000002 153.9 154 jp@gc - Dummy Sampler all
1616507451817000000 148.7 151.89999999999998 154 jp@gc - Dummy Sampler all
1616507456814000000 145 149.95 154 jp@gc - Dummy Sampler all
1616507461816000000 148.70000000000002 151.95 155 jp@gc - Dummy Sampler all
1616507466817000000 148.8 151.95 154.99 jp@gc - Dummy Sampler all
Что же произошло? Ответ кроется в том как DescriptiveStatistics считает персентили. Они юзают следующий алгоритм
http://www.itl.nist.gov/div898/handbook/prc/section2/prc252.htm
The pth percentile is a value, Y(p), such that at
most (100p)% of the measurements are less than this
value and at most 100(1 - p)% are greater. The 50th
percentile is called the median.
Percentiles split a set of ordered data into
hundredths. For example, 70% of the data should fall
below the 70th percentile.
Note the use of "at most," which is necessary in order to make the definition work. In particular, the lowest and highest values are the 0th and 100th percentiles.
It does NOT say that 100% of the values are LESS than the 100th percentile; the "should" in the last sentence above is a general statement, not the actual definition.
То есть их логика немного отличается от того как считает джиметр. Джиметр берет в качестве персентиля конкретное значение респонс тайма семпла, а DescriptiveStatistics считает свое значение. И, к примеру, значение 90% должно быть такое что остальные 10% респонс таймов должны быть больше, НО само значение персентиля не будет одним из списка.
Теперь давайте проверим:
155
154
154
152
152
151
150
150
150
149
148.8 - 90% influxdb. Действительно, значение немного отличается, но это всеравно правильный и валидный 90 персентиль
147 - 90% jmeter 10%, или в нашем случае просто 10 семплов лежат выше в отсортированом списке респонс таймов
147
Так что подсумируя еще раз:
- в jmeter.properties меняем
backend_metrics_window_mode=timed
backend_metrics_window=50000(или другое большое число, больше чем количество семплов за тест)
backend_metrics_large_window=50000(или другое большое число, больше чем количество семплов за тест)
- в графане в панельках, где вы трекаете тренды юзаете avg, так как оно станет показывать значение за 5 сек
- в графане в таблицах считаете персентили через last("pct90.0"), а среднее через mean("avg")
и будет вам счастье 🙂
