Hello, Thanks for this proposal.
It looks a good idea. But I would keep Thread Group as is for the following reasons: - Backward compatibility although I see you propose a solution - Tests that require rampup. I think it is useful to have this. - Some simulations want to test a degree of parallelism and see behaviour Regards On Thu, Oct 14, 2021 at 8:58 PM Vladimir Sitnikov < [email protected]> wrote: > Hi, > > Some time back I contributed "Precise Throughput Timer" which enables uses > to throttle requests to a certain throughput (see [1]) > It works, however, there are issues with that approach: > a) It is not that easy to configure the thread group. Default thread group > creates threads on regular intervals which does not work well for the > desired exponentially distributed intervals. > b) If all the threads are created at the beginning, then it creates a high > overhead. If non-zero ramp-up is configured, then it might result in "not > enough threads" condition. > c) "ramp up" seems to be not that useful for a thread group > d) The thing gets harder to use for longer tests. E.g. 7day testing plan > might surface "wrong rampup" issues quite soon > > I think behind the lines of pivoting "thread group" configuration as > follows: > 1. remove "rampup", remove "delay" > 2. add a free-text field for configuring the load profile (something like > in Ultimate thread group [2]) > For instance: delay(2s) fire(100samples during 30min) delay(10s) > fire(500samples during 30min) > I have no idea what the DSL should be, however, it looks the approach would > work for replacing the default thread group element. > > WDYT? > > [1]: > > https://jmeter.apache.org/usermanual/component_reference.html#Precise_Throughput_Timer > [2]: > > https://jmeter-plugins.org/wiki/UltimateThreadGroup/#Special-Property-Processing > > Vladimir > -- Cordialement. Philippe Mouawad.
