а где ж его взять)

я бы с радостью любой DSL юзал

но с покрытием у них проблемы массовые, надо контрибьютить.

Спасибо большое, уже разобрался. Там кстати на примере выше https://easyjmeter.wordpress.com/2015/09/10/creating-a-java-sampler-for-jmeter/ используется java.net.URL к качестве http клиента. Вычитал, что URL при отправке больших данных может сбоить, и начал писать, используя Apache HttpClient. Это вообще норм? Кто что использует?

И вообще, любой хттп клиент можно тащить?

http client 4 - надёжная штука, можно его смело юзать

окей, спасибо

А я вот подумал, что Kotlin DSL к штатным классам можно и закоммитить и в сам JMeter

план безумно годный)
работа большая и не думаю что быстро взлетит.
если реально будете двигаться в этом направлении - скажи плз)

Начать можно с того, чтобы стырить DSL у java-dsl

там ещё понять - он вообще норм или нет. я не ревьювил

Всем привет.
Может кто-нибудь, пожалуйста, подсказать по backendlistener в jmeter (который агригирующий):
1. backend_metrics_window устанавливает размер окна в разрезе каждого запроса или для всех запросов в сумме?
2. Каким образом можно получить максимальную точность? Подойдёт например интвервал 1s, mode timed, и размер окна, который будет достаточным для хранения данных за интервал?

может быть полезно #backendlistener

Уже общались по этому поводу в другом чате, но решил еще тут пошарить информацию, так как складывается ощущение что много кто не понимает как работает агрегация в стандартном influxdb backend listener.

На деле стандартный бекенд лисенер по дефолту агрегирует данные не за 5 секунд, как может показаться на первый взгляд, а немного по другому. Лисенер под капотом использует либу DescriptiveStatistics, которая позволяет получать в рантайме разного вида агрегации. Джиметр создает себе несколько датасетов:
- okResponsesStats
- koResponsesStats
- allResponsesStats
- pctResponseStats
По сути датасет это такой себе бакет, куда джиметр будет добавлять респонс таймы, а DescriptiveStatistics будет считать разные агрегации по требованию джиметра, например "koResponsesStats.getPercentile(percentile);"
У каждого датасета есть свой максимальный размер, который можно передать в jmeter.properties файле.

В jmeter.properties есть вот такие параметры:
# Backend metrics window mode (fixed=fixed-size window, timed=time boxed)
#backend_metrics_window_mode=fixed
# Backend metrics sliding window size for Percentiles, Min, Max
#backend_metrics_window=100
# 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=5000

Так вот, если максимальный размер датасета к примеру 100 и в него уже добавлено 100 значений, новое значение пойдет перетирать первое в нем и так далее.
А теперь разберем пример:
За первые 5 сек теста джиметр выполнил 2 запроса Login с респонс таймами 100 и 200мс
- okResponsesStats(100,200)
- koResponsesStats()
- allResponsesStats(100,200)
- pctResponseStats(100,200)
при отправке данных джиметр попросит DescriptiveStatistics посчитать avg, pct(90,95,99), min, max. Avg например получится 150мс, что и отправится в инфлюкс

Дальше за вторые 5 сек отправилось еще 3 запроса, один из них свалился, в итоге датасеты выглядят вот так:
- okResponsesStats(100,200,120,160)
- koResponsesStats(190)
- allResponsesStats(100,200,120,160,190)
- pctResponseStats(100,200,120,160,190)
при отправке данных джиметр попросит DescriptiveStatistics посчитать агрегации и либа опять посчитает их на основании всех данных что есть в бакете, то есть avg будет не по (120,160,190) а по всем (100,200,120,160), что тупо с точки зрения мониторинга, так как на графиках в графане я хочу видеть значения среднего как раз за промежутки в 5 сек, а не пересчитывание данных с начала теста.

Для того что б исправить это, нужно изменить значение проперти backend_metrics_window_mode с fixed на timed.
После этого джиметр начнет очищать датасеты okResponsesStats, koResponsesStats, allResponsesStats после каждой отправки данных в инфлюкс, что нам и нужно.

Теперь по поводу персентилей, датасет pctResponseStats не очищается при любых значениях backend_metrics_window_mode, так как персентили нас интересуют не за 5 сек, а за весь тест. Нас интересует последнее значение персентиля для транзакции, которое бекенд лисенер отправляет в инфлюкс. Основная проблема в том что значения не совпадают с тем что показывает джиметр это то что дефолтное значение backend_metrics_window=100, а это значит что 101 и все остальные семплы будут просто начинать перетирать 1,2... значения в pctResponseStats датасете, и в результате в конце теста лисенер посчитает персентиль только за последние 100 семплов. Для того что б значение персентиля было максимально правдивым, нужно поставить в backend_metrics_window большое значение, в идеале больше чем количество семплов что выполняются за тест. При таком раскладе до конца теста pctResponseStats будет в себе хранить все респонс таймы и сможет спокойно посчитать правильный персентиль.
Так что мой совет ставить timed и большие значения в оба backend_metrics_window и backend_metrics_large_window

Ура, но если проверите, то скажете что всеравно не работает, цифры отличаются от того что дает джиметр.
Что я только что протестил для демо: запустил тест на 100 семплов, отсортировал по убыванию респонс таймы и вот мои топ 12 запросов в мс:
155

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")
и будет вам счастье 🙂

Спасибо, полезная инфа.
Если я верно понял то окно устанавливается в итоге для каждого запроса?
Кто-нибудь пробовал использовать большие значения для окна, чтобы считать pctResponseStats? Мне кажется память выжрется успешно, если говорить про значения в сотни миллионов.
Не подойдёт вариант ставить значение, чтобы хранить данные за интервал?
И как вообще обычно делается, все уходят в то, чтобы лить сырые данные, или проще смириться с погрешностью агрегации?)

Ну это лайк за такие обсуждения и эксперементы

спасибо за исследование, интересненько

замечал, что в графане выше время отклика чем по логу метра