You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2020/12/27 18:57:24 UTC
[Bug 65031] New: Ramp-up period not accurate
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
Bug ID: 65031
Summary: Ramp-up period not accurate
Product: JMeter
Version: 5.2.1
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: minor
Priority: P2
Component: Main
Assignee: issues@jmeter.apache.org
Reporter: rabelenda@gmail.com
Target Milestone: JMETER 5.4.1
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
--- Comment #4 from rabelenda@gmail.com ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
--- Comment #3 from Felix Schumacher <fe...@internetallee.de> ---
Created attachment 37672
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37672&action=edit
Change calculation of rampup deltas
Change the delta to variant three. Start right away, but wait longer for each
thread.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
--- Comment #5 from Felix Schumacher <fe...@internetallee.de> ---
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 <fe...@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(-)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable
OS|Mac OS X 10.1 |All
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
Felix Schumacher <fe...@internetallee.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Felix Schumacher <fe...@internetallee.de> ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 65031] Ramp-up period not accurate
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031
--- Comment #1 from rabelenda@gmail.com ---
Tested with jmeter 5.2.1 and 5.4.
--
You are receiving this mail because:
You are the assignee for the bug.