KY
можно даже из jsr223
Size: a a a
2020 November 13
KY
если нужно имитировать запись дефолтного листнера могу подсказать как
K
в целом можно вручную писать данные в инфлюкс и генерить их. всего то нужно посчитать от одного запроса до другого время (а-ля транзакция) и сделать http request по апишке
Боюсь это уже лишнее, но спасибо
ВС
Kostya
Предположим сам transaction controller называется Test,нужно чтобы с помощью jsr assertion он попал в инфлюкс с названием My_Test
Способ с переименованием, что вы описали, работает для Sampler.
Используйте Sampler вместо TC.
Используйте Sampler вместо TC.
K
Способ с переименованием, что вы описали, работает для Sampler.
Используйте Sampler вместо TC.
Используйте Sampler вместо TC.
Спасибо,а есть нечто подобное для TC?
ВС
Kostya
Спасибо,а есть нечто подобное для TC?
Оказалось, что только JSR223 Listener принимает события от Transaction Controller без галочки Generate Parent Sample.
Используйте JSR223 Listener для переименования
Используйте JSR223 Listener для переименования
ВС
sampleResult.setSampleLabel("amazing_text " + sampleResult.getSampleLabel())
OC
Коллеги, встречаюсь что то первый раз с таким:
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
ВС
Коллеги, встречаюсь что то первый раз с таким:
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Для метрик mean, max в csv и в InfluxDB попадают одни и те же числа.
Исключения могут быть, если JMeter Backend Listener был не в корне Test Plan, а где-то в одной из многих катушек или транзакций. Если контекст Backend Listener и контекст формирования CSV-лога были разными.
И сравнение между JMeter HTML Report и Grafana Dashboard, если да, то каким, хорош ли он?
Исключения могут быть, если JMeter Backend Listener был не в корне Test Plan, а где-то в одной из многих катушек или транзакций. Если контекст Backend Listener и контекст формирования CSV-лога были разными.
И сравнение между JMeter HTML Report и Grafana Dashboard, если да, то каким, хорош ли он?
ВС
Доверяю HTML Report, когда выверял Grafana Dashboard, то ориентировался именно на HTML Report.
ВС
Посмотрите разные варианты Dashboard. Если понравится jmeter.json отсюда
https://github.com/polarnik/loadlab_vm/tree/master/ansible/content/grafana/dashboards/json
буду рад, она для базового InfluxDB Backend Listener
https://github.com/polarnik/loadlab_vm/tree/master/ansible/content/grafana/dashboards/json
буду рад, она для базового InfluxDB Backend Listener
K
Коллеги, встречаюсь что то первый раз с таким:
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Я бы метрики в самом инфлюксе глянул,если они соответствуют jmeter лисенерам,то смотреть в квери дашбордов графаны
K
Огромное спасибо! Именно такой вариант и искал,без костылей и крови.
2020 November 14
AK
Для метрик mean, max в csv и в InfluxDB попадают одни и те же числа.
Исключения могут быть, если JMeter Backend Listener был не в корне Test Plan, а где-то в одной из многих катушек или транзакций. Если контекст Backend Listener и контекст формирования CSV-лога были разными.
И сравнение между JMeter HTML Report и Grafana Dashboard, если да, то каким, хорош ли он?
Исключения могут быть, если JMeter Backend Listener был не в корне Test Plan, а где-то в одной из многих катушек или транзакций. Если контекст Backend Listener и контекст формирования CSV-лога были разными.
И сравнение между JMeter HTML Report и Grafana Dashboard, если да, то каким, хорош ли он?
А можно подробнее, в каких случаях могут быть разные данные у backend listener в катушке и csv и как влияет контекст? Или что погуглить.
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
jj
А можно подробнее, в каких случаях могут быть разные данные у backend listener в катушке и csv и как влияет контекст? Или что погуглить.
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
никакой избыточности не чувствуете а?
ВС
А можно подробнее, в каких случаях могут быть разные данные у backend listener в катушке и csv и как влияет контекст? Или что погуглить.
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
У меня на проекте backend listener помещают в каждый запрос отдельно и верят именно этим данным. А теперь звучит как будто здесь есть подвох и при сверке с csv не сойдется🧐
Спасибо вам. Совсем забыл, что Backend Listener ещё аггрегирует метрики. А в csv все метрики "сырые", там нет max, mean.
Буду думать медленнее.
А по множественным Backend Listener, возможно, это оправданно. Если нужны разные TAG_... поля. Или если особенности аггрегации влияют на результат, тут надо разобраться
Буду думать медленнее.
А по множественным Backend Listener, возможно, это оправданно. Если нужны разные TAG_... поля. Или если особенности аггрегации влияют на результат, тут надо разобраться
ВС
Коллеги, встречаюсь что то первый раз с таким:
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Проводил тестирование производительности(снятие базовых метрик) и анализирую сейчас данные логов из графаны и jmeter.
Клиентская машина находится в нагрузочном контуре с минимальным пингом.
Смотрю на логи клиента-jmeter, там среднее 10-20 мс, а логи графаны: 200-300 мс
Причем все логи от jmeter плюс минус одинаковы(что 190 рпс, что 800 рпс)
Что может быть?
Разные данные CSV <-> Grafana также из-за аггрегации. Backend Listener аггрегирует метрики. CSV нет
AK
никакой избыточности не чувствуете а?
Если вы про listener'ы в каждом запросе - так вот написано, это нелегально? Используются самописные listener'ы. Не готова сказать, почему в каждом запросе отдельно, не разбиралась еще.
Мой вопрос был скорее про то, разную ли длительность запроса (условно) видит listener в зависимости от его расположения.
Мой вопрос был скорее про то, разную ли длительность запроса (условно) видит listener в зависимости от его расположения.
AK
Спасибо вам. Совсем забыл, что Backend Listener ещё аггрегирует метрики. А в csv все метрики "сырые", там нет max, mean.
Буду думать медленнее.
А по множественным Backend Listener, возможно, это оправданно. Если нужны разные TAG_... поля. Или если особенности аггрегации влияют на результат, тут надо разобраться
Буду думать медленнее.
А по множественным Backend Listener, возможно, это оправданно. Если нужны разные TAG_... поля. Или если особенности аггрегации влияют на результат, тут надо разобраться
А, кажется поняла, если listner'ы аггрегируют, то в зависимости от положения могут выдать разный результат. Но сырые данные от csv не отличаются. Так?
jj
в csv и есть сырые данные