Hi, Vladimir, will your new thread group allow to simulate open system? I think about defining new request arrival at defined rate (or characteristic) irrespectively of number of threads in system (and created by generator). Something like described in: https://www.cs.cmu.edu/~bianca/nsdi06.pdf
If so, what thread(X) will mean in: " 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)" ps. I don't looked at code yet so I don't know how it is implemented now:) I may also not fully understand the functionality of the new component yet. Regards, Mariusz On Sat, 6 Nov 2021 at 12:53, Vladimir Sitnikov <[email protected]> wrote: > 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 >
