Bug 65031

Summary: Ramp-up period not accurate
Product: JMeter Reporter: rabelenda
Component: MainAssignee: JMeter issues mailing list <issues>
Status: NEEDINFO ---    
Severity: minor Keywords: PatchAvailable
Priority: P2    
Version: 5.2.1   
Target Milestone: JMETER 5.4.1   
Hardware: PC   
OS: All   
Attachments: Change calculation of rampup deltas

Description rabelenda 2020-12-27 18:57:24 UTC
There seems to be a problem in calculation of ramp up period according to the documentation. 

The documentation states:

"The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds."

But doing some simple tests, if I set ramp-up period to 10 seconds, and 1 thread, the thread starts without any delay (so, full number of threads is reached in 0 time). If I use 2 threads, then first thread starts immediately and second thread starts after 5 seconds (reaching full number of threads at 5 seconds).

In general it seems that if ramp-up period is set to X seconds, and there are Y threads, the time taken to start all the threads is X - X/Y.

This is not a major issue, but one that may confuse users and that requires additional calculation to get the proper desired ramp-up.
Comment 1 rabelenda 2020-12-27 19:06:50 UTC
Tested with jmeter 5.2.1 and 5.4.
Comment 2 Felix Schumacher 2020-12-30 10:41:20 UTC
The main problem here, is that the delay is not added to the first thread. If we would change this, I think it would add up all nicely.

The reasoning was probably, that the test should start right away instead of waiting some time (The user pressed start, why didn't it start?).

I think, we have three possible ways to solve this:

1) do nothing (nobody else seems to care ;) )

2) start with a delay and everything should be fine (apart from those, that expect an instant start)
  That is delayPerThread = rampUp / nr_of_threads and start time = now + thread_nr * delayPerThread (thread_nr starting from 1!)

3) start right away and calculate the differences between the threads by subtracting one from the number of threads.
   That is delayPerThread = rampup / max(nr_of_threads - 1, 1) and start time = now + thread_nr * delayPerThread (thread_nr starting from 0!)

I tend to changing the behaviour to variant three (longer delayPerThread and instant start)

@all what do you think?
Comment 3 Felix Schumacher 2020-12-30 10:51:37 UTC
Created attachment 37672 [details]
Change calculation of rampup deltas

Change the delta to variant three. Start right away, but wait longer for each thread.
Comment 4 rabelenda 2020-12-30 13:21:05 UTC
Hello,

I think 3rd option has a good balance, but maybe something needs to be added to documentation about the first thread, and the special case when you have only 1 thread. For example, by default thread group is initialized with 1 thread and 1 second ramp up, but that ramp up will never be applied, maybe 0 would be a more adequate value in such case, but changing the default value also makes test plans that change the thread group number to no longer ramp up by default.

I think the 2nd option is simpler and potentially more intuitive alternative, but has the issue you mention (test not starting right away, unless use 0 and start all threads at the beginning of the test). 

Another option (we might call it 3b) might be to allow the user to set the behavior through a JMeter property, eg: START_FIRST_THREAD_IMMEDIATELY (it could be initially set to false, and in later version of JMeter, with proper warning to users, change it's default value to true). I personally would avoid using JMeter properties because they look like hidden features, add to the general complexity of the app (you have another "IF" in your logic), and in many cases are under documented (you have to dig into code to find the existence of such properties).

A final option (that is aligned with your 1st option, and might call it 1b) is just changing documentation to reflect current behavior. That would avoid other users potentially reporting this issue in the feature, avoid changes in logic for users that have already implemented logic based on current behavior, but would still leave some inconsistency for users using the UI and not checking documentation.

Best regards, and thank you to look into this.
Comment 5 Felix Schumacher 2020-12-30 15:04:07 UTC
Added the current behaviour as a note to the documentation of Thread Group.

I still think, we should go with version 3, that is start immediately and enlarge the periods between the threads to fill the complete ramp-up time. (But that might be better done after the next release, which should be a minor release)

commit 777e400a3ca3de49e61ff1931e4edc0c716ad26e
Author: Felix Schumacher <felix.schumacher@internetallee.de>
AuthorDate: Wed Dec 30 15:27:10 2020 +0100

    Clarify ramp-up period
    
    add a bit of markup, too
---
 xdocs/usermanual/component_reference.xml | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)