Delay Thread creation until needed

[Apolayo27]

how can I select from jmeter-dsl to delay the creation of threads until they are needed similar to .sampleErrorAction(BaseThreadGroup.SampleErrorAction.START_NEXT_ITERATION)

[rabelenda]

Hello, thank you for taking the time to try the library and ask this question.

I see in the image that you are pointing not only to the delay but same user on each iteration. Can you give more details of what are you trying to achieve in your test plan that might need such behavior?

Additionally, why do you need the delay thread creation until needed? Can you give more insights? This would help us properly design the api and provide proper documentation and guidance to users on when to use each feature.

Regards

[Apolayo27]

Hi, thanks for your prompt reply

Same user on each iteration: In my use case I need the cookies and cache to remain between iterations that's why I check the checkbox.

Delay Thread creation until needed: In my use case I need that the resources are not created at the beginning of the test but until the resource needs to be created, for a better handling of the tps.

[rabelenda]

Can you provide examples of thread group configurations to try to understand better?

Regarding same user on each iteration: can it be solved using a for loop or while iterator?

How are you seeing tps affected by delaying thread creation? In this case we use as default the same default JMeter uses, and we think in general this setting to be a good default, to avoid thread creation "cost" interfering with test plan execution (by creating threads before time). In some particular scenarios this might not be desirable, but I would like to understand your use case better to give you and the community a good and simple solution for use cases like the one you use.

Thank you for taking the time for giving more detail.

Regards

[Apolayo27]

In certain cases, there may be times when not all users are performing actions simultaneously, resulting in periods of inactivity. To realistically simulate this behavior, it is useful to delay the creation of threads until they are needed. Instead of creating all threads at the start of the test, delaying the creation of threads allows to reflect the behavior of real users and reduces the initial load on the system under test.

testing a web application that uses user sessions, to simulate on-demand login and session creation. Instead of starting all threads with user sessions at the beginning of the test, delaying thread creation until users perform actions that require a session provides a more accurate simulation of real user behavior. In addition, this strategy avoids initial overhead on the application server, since threads are only created when user sessions are needed.

[rabelenda]

Hello,

Threads creation controlled by the checkbox property (delayed vs not delayed) is in general independent from the load imposed to the system under test. Is a technical aspect on when the JVM threads are created, and for how long they live. The generated load to the system under test is always ruled by ramp up period, max threads, etc. The main difference between using the checkbox or not, is if you don't mark it, internally JMeter creates all threads at the beginning but delays the execution of each thread iteration according to configured rampup, emulating desired behavior. When you enable the checkbox each thread is created as it is needed during rampup.

Main differences might be perceived in JMeter resources consumption (ram & cpu) and how this technical details affect execution of the test plan (since ram & cpu usage might affect sampler measurements). For instance, if you are configuring a lot of threads without checking the checkbox, all threads will be created at the beginning of execution, with potential impact (CPU) at the beginning and potentially consuming unnecessary memory until the rampup period completes. On the other hand, this option avoids potential load (mainly cpu) imposed in the creation of each thread during rampup (potentially affecting collected metrics for a longer period when using long rampups).

I think the main difference is noticed when you configure a lot of threads that are short lived, and that some threads end before other have been created. Which is the main use case listed in JMeter documentation for this option. For example: 1000 threads with 1 iteration each, with at maximum 10 threads running each time. In general, there are scenarios where this is not true, is better (since consumes less resources) to just create fewer threads and adapt thread logic to properly emulate same behavior. Eg: 10 threads with 100 iterations each in previous example. Since JMeter DSL is configured by default to reset cookies and connections between iterations, in general (again), this gets you the expected behavior, with low resources impact.

Does this clarify or help?

Have you identified scenarios where you have seen a considerable difference between using delay thread execution option and not using it?

Can you share some example test plan configuration (no need for httpSampler details), but mainly number of threads, rampup, threads duration or iterations, expected generated load to system under test?

Thank you again for the patience and helping me understand your need :).

[rabelenda]

@Apolayo27 have you had a chance to review my previous comment?