Felix>I think the old ThreadGroup has a nice and simple interface, that can be Felix>understood in a short time (my opinion :))
Well, the old thread group easily configures "N threads", however, as soon as you need to set the desired request rate you are out of luck :-) One of the key questions is "how many threads do I need?", and there's no single answer since you don't want to over-provision and have 10000 idle threads. Other solutions involve more intimate integration between the thread group and the shaping timer (see https://jmeter-plugins.org/wiki/ConcurrencyThreadGroup/#Use-With-Throughput-Shaping-Timer-Feedback-Function), however, I would say the resulting configuration is far from being intuitive. Well, even placing a single timer in JMeter requires a PhD, so asking "thread group + timer + feedback function" does not seem to be good for UX. ---- Just in case, I did consider adding something like "feedback function" to the existing thread group, however, it looks like the only use cases I have at hand are "making the test produce the desired load without overprovisioning the threads". In other words, integrating the load profile into the thread group covers all my cases and it yields easier to understand configuration. Felix>That should probably be run on some users and hear their feedback I'm glad you asked. Suggestions are welcome. I did announce the thread group on Twitter: https://twitter.com/VladimirSitnikv/status/1455141600213012489 I announced it in qa_load Telegram chat (Russian-mostly, ~3800 participants): https://t.me/qa_load/68193 I got exactly 0 comments/suggestions regarding the semantics :-/ The first comment I got was "please add a chart", and then someone managed to get what they wanted with the following config: ${__groovy(def result = ""; for (def i=0;i<10;i++) { def pattern = " random_arrivals(%ss) rate(%s/sec) random_arrivals(%ss)"; def step = props.get("start") + props.get("step")*i; result=result+String.format(pattern\, props.get("ramp")\, step\, props.get("duration")); }; return result;)} A good thing is that when the properties are present in jmeter.properties, then the UI displays the load profile even in case it is built via Groovy script. In case you wonder the groovy expression above evaluates with start=28, step=28, ramp=60, duration=300 as follows: random_arrivals(60s) rate(28/sec) random_arrivals(300s) random_arrivals(60s) rate(56/sec) random_arrivals(300s) random_arrivals(60s) rate(84/sec) random_arrivals(300s) .... which is "increase load from 0 to 28/sec during 60 sec", "hold 28/sec for 5 minutes" "increase load from 28/sec to 56/sec during 60sec", "hold 56/sec for 5 minutes" "increase load from 56/sec to 84/sec during 60sec", "hold 84/sec for 5 minutes" ... ---- I was trying to avoid multi-argument "methods" since there's no autocomplete in JMeter UI, and you never know the order and the meaning of the arguments. That is why I went with one-argument "rate(4/sec)" and "random_arrivals(5 min)". The open question is how "the number of threads" should be configured, and I think it would go via threads(8). For instance, "10 threads, during 1min": rate(100500/ms) threads(10) random_arrivals(1 min) "start from 1 thread doing 1/sec and gradually go to 10 threads doing 100/sec in 1 min" threads(1) rate(1/sec) random_arrivals(10 min) threads(10) rate(100/sec) "threads(.)" and "rate(.)" could be put in any order. Felix>But as Vladimir explained, it would add a Felix>lot of unwanted dependecies in the core The overall increase is 16MiB where 1.8MiB is for kotlin-stdlib, and the rest is Apache Batik (for SVG) and lets-plot (for charting). I hope lets-plot does not need kotlin-reflect (2.9MiB): https://github.com/JetBrains/lets-plot/issues/471 However, I think the chart does make it way easier to understand the load profile, so even 16MiB increase is ok. One of the options would be to split "core" into "core-impl" and "core-ui" where core-ui depends on core-impl and various UI libraries. That might be helpful for all the modules so non-gui users (e.g. via Maven or Gradle) do not have to pull UI dependencies. However, I think we can split modules later. On the other hand, jmeter-java-dsl has a clever mode when they launch "View Results Tree" Swing UI: https://abstracta.github.io/jmeter-java-dsl/guide/#view-results-tree, so they would depend on "view results tree UI" module anyway. Felix>* New contributors falling out of the sky Felix>I would like to see that happen, but haven't observed it, yet :) Looks like Kotlin won't make it worse :-) Felix>don't know the state of Felix>usability it has reached regarding Kotlin Frankly speaking, I've no idea how it works in Eclipse. Vladimir
