Просто узнать насколько широко пользуются, и вообще есть ли такие.

Народ, вы откуда?
Обычно с конференций приходят, может мы что-то пропустили?

В другом чате дали ссылку на этот.

Добрый день! А можно ведь как-то сохранить переменную в Java Request коде программно и далее как-то прокинуть/переиспользовать ее в самом джиметре?

Или это решается постпроцессорами?

vars.put/get props.put/get

Добрый день. Да, через Context.
В методе выполнения есть параметр context. Используйте его API
как в примере простого JavaRequest:
https://github.com/apache/jmeter/blob/master/src/protocol/java/src/main/java/org/apache/jmeter/protocol/java/test/JavaTest.java#L270

У context есть метод getJMeterContext()
https://github.com/apache/jmeter/blob/v5.4.1-rc2/src/protocol/java/src/main/java/org/apache/jmeter/protocol/java/sampler/JavaSamplerContext.java#L234

У которого есть методы getVariables() и setVariables(JMeterVariables vars)
https://github.com/apache/jmeter/blob/v5.4.1-rc2/src/core/src/main/java/org/apache/jmeter/threads/JMeterContext.java#L104

У списка переменных есть метод put:
https://github.com/apache/jmeter/blob/v5.4.1-rc2/src/core/src/main/java/org/apache/jmeter/threads/JMeterVariables.java

Получается код будет такого вида

String varName = "name";
String varValue = "123";
org.apache.jmeter.threads.JMeterVariables vars = context.getJMeterContext().getVariables();
vars.put(varName, varValue)
context.getJMeterContext().setVariables( vars );

или с промежуточными переменными для контекста

Ага, работает 👍🏻👍🏻
Отдуши, господа!

Инструменты мало используются именно в среде тестирования производительности.
Это выбор команд разработки, которые сами пишут на Erlang и хотят поддерживать единую кодовую базу для всех частей проекта.
Если вы в такой среде, и цель в том, чтобы команда разработки поддерживала тесты производительности, или важно переиспользовать библиотеки в коде, то выбор разумен - если свои плагины писать для tsung.

Консультировать именно по особенностям инструмента будет сложно. XML-язык, как в JMeter.

Когда-то tsung был прорывным, подкупал своей асинхронностью, тем, что поддерживал WebSocket, а больше никто это не поддерживал.
Но так было 10 лет назад.
Потом появились плагины в JMeter для WebSocket, потом появился Gatling, который совместим с более распространенной экосистемой JVM.
И про tsung как-то забыли. Это глазами команды нагрузки отдельно взятой компании

mzbench выглядит интереснее, синтаксисом

А чтобы сформировать профессиональное мнение, я бы почитал как сделаны тесты производительности в крупных проектах.
В RabbitMQ

А в RabbitMQ (наиболее известном мне проекте на Erlang)
тесты производительности написаны на Java:
https://github.com/rabbitmq/rabbitmq-perf-test

Поэтому, буду советовать вам смотреть инструменты на Scala/Java, если вы инженер нагрузки: Gatling, JMeter
А если разработчик, то в выборе mzbench / tsung - выбирать mzbench за более приятный синтаксис

CouchDB в Phoronix тестируют по HTTP через Curl:
https://openbenchmarking.org/test/pts/couchdb
вот таким скриптом:
http://www.phoronix-test-suite.com/benchmark-files/apache-couchdb-benchbulk-1.tar.xz

А другой проект по тестированию написан на Java тоже:
https://github.com/mgp/iron-cushion

А вот у EMQX тесты написаны ими самими уже на Erlang:
https://github.com/emqx/emqtt-bench
Но это не тесты на tsung, а своя утилита

добрый день, уважаемые знатоки НТ! помогите, пож-та, новичку с первым тестом) есть задача  - найти максимум пользователей, которых выдержит система при определенном кол-ве обращений к странице в сутки. я нашел интенсивность и составил профиль нагрузки, но совсем запутался, какой рпс нужно подставить в трупут шейпинг таймер для формирования этой интенсивности… собственно, вопрос, правильно ли я делаю, если я задаю рпс, найденный по формуле RPS = 1000/T(мсек)*threads, где за Т принимаю максимально допустимое время выполнения запроса?

у тебя есть профиль, внутри него и написаны рпсы. в зависимости от того где у тебя шейпинг таймер ты должен подставить в него разные рпсы. если шейпинг в корне, значит суммарный рпс всех методов, если вначале и дочерний элемент относительно flow action control тогда входной рпс или максимальный в зависимости от сценария

простой пример. твой профиль одна операция - логин. у нее по профилю 10 рпс. что подставить в шейпинг таймер? 10 рпс. тредов должно быть с запасом по формуле максимальный отклик логина * 10 рпс (или на максимальный если есть рост). чтобы сделать запас можно докинуть к результату + 100

теперь второй пример. у тебя логин и логаут, первый 10 рпс, второй магическим образом 5 рпс. делаешь флоу экшн контроль и дочерним элементов делаешь шейпинг таймер в котором 10 рпс. далее в скрипте логаут делаешь дочерним элементом трупут контроллера внутри которого 50 процентов. треды считаешь как сумму максимальных откликов * суммарный максимальный рпс например и опять +100

в первом случае у тебя 10 рпс на одну операцию во втором 10 на логин 5 на логаут

есть вопросы?

спасибо! теперь вроде все разложилось по-полочкам, а то слишком много теории было за последнее время, и стали брать сомнения…

Спасибо за развернутый ответ. Собственно так и предполагал. Сам эрлангист, и для меня mzbench более предпочтителен. У самого такой бекграунд есть. Просто было интересно узнать кто еще пользует это. Но по ходу 0.5 человека только.

было пару видео от фанатов

Всем привет, кто-нибудь пробовал использовать для мониторинга кафки KafkaTool ? Как оно? требуется мониторить не вычитанные сообщения в топике

Consumer Lag можно мониторить через Prometheus Exporter и другие средства

Это имеется в виду же, Consumer Lag, а не количество сообщений ?