в смысле не 10?

dsl мастхев для больших масштабов. у тебя 20 команд, внутри каждой тонна скриптов. как отревьювить быстро скрипт или понять его логику? по названию? нет надо каждый качать себе на тачку с экраном и там смотреть. как сделать переиспользуемый куски скриптов? include и module контроллеры? ну тоже значит несколько жметров открой, понимай как там всё устроено да связано. как массово нейминг поменять? парсить xml? ну это же дичь)
плюсуем туда сомнительную реализацию классов, например написал ты классный генератор данных или даже просто мапу какую-то сделал. это тебе надо её сначала заинитить одном месте, потом брать внутри тредов в каких то глубинах дочерних элементов и там наполнять. и это всё ладно, но как нормально дебажить? я понимаю кнеш что log.info придумали боги, но когда ты видишь в дебаггинге полный контекст треда и жава машины - тебе как то проще)
финальный аккорд - это возможность создания скриптов самими разработчиками, в рамках гуя jmeter - это для них дичь и боль, как с точки зрения хранения версий скрипта так и с точки зрения его разработки. а тут у тебя as a code решение - бери да разбирайся, поддерживай фичи которые тебе нужны на проекте, переиспользуй общий package и тд

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

тотемные звери тоже нужны ладно

каланчик стукается с тобйо кулачком

нормальный пацан

Понял, спасибо за развёрнутый ответ)

ну это я к чему - поддерживаю дсл, не вижу как можно в жмитере командой работать

можно если автоматизировать разработку скрипта до максимума)

Накидано много, поэтому выберу произвольный пункт и опровергну его:

>но как нормально дебажить?

DSL != возможность дебажить скрипт.

Как-никак, а, все текущие DSL к JMeter лишь генерируют скрипт, а выполняется оно всё равно силами JMeter. Например, если написать скрипт на java-dsl-jmeter (или как оно там), то поставить точку остановки в этом DSL, конечно, можно, но она сработает не в момент выполнения, а в момент, когда из dsl генерируется jmx.

https://abstracta.github.io/jmeter-java-dsl/guide/#post-processor-breakpoints лучше или хуже log.info?)

ну когда всё само то и грузчики не нужны)

и наконецто можно позаниматься перформансом)))

А что ты тогда на гатлинг не переходишь?

ну тут же  не стоит вопрос: надо просто писать любой код. стоит вопрос стека, скорости перехода, наличия компетенций. в команду разработки на питоне ты же не придёшь и не скажешь а давайте теперь все на js переделаем?)

Имхо между выбором «переходить на сырой dsl к жметру» или «переходить на опробованный dsl к гатлингу» - я скорее за гатлинг буду

Но, конечно, в минусе будут куча вещей, которые тогда придётся с нуля выдумывать, это да

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

гатлинг в след версии будет на котлине и джаве

а DSL поменяется?