[Bug 65031] Ramp-up period not accurate
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 --- Comment #5 from Felix Schumacher --- 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 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
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 --- Comment #4 from rabele...@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
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 Felix Schumacher 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
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 --- Comment #3 from Felix Schumacher --- Created attachment 37672 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37672=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
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 Felix Schumacher changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Felix Schumacher --- 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
https://bz.apache.org/bugzilla/show_bug.cgi?id=65031 --- Comment #1 from rabele...@gmail.com --- Tested with jmeter 5.2.1 and 5.4. -- You are receiving this mail because: You are the assignee for the bug.
