On 02/03/2010, Brett Cave brettc...@gmail.com wrote:
Hi,
A thought on the logic used for thread groups:
As a JMeter user, would I want to configure a total number of users to
simulate over a time period, with delays in order to achieve this, or would
it be more practical from a testing point of view to set a target
Concurrent threads with a ramp-up period to get to this number of threads?
The current logic caters for the first scenario:
float perThreadDelay = ((float) (rampUp * 1000) / (float) numThreads);
for (int i = 0; running i numThreads; i++) {
jmeterThread.setInitialDelay((int) (perThreadDelay * i));
}
So if I set # threads in a group to 100 with a rampup of 100, then I will
get 100 threads in total, with each thread starting up 1 second after the
last.
My original thinking when designing the plan was target concurrent threads
at end of rampup period.
Would it be a useful feature to have a thread group that can ramp up to the
target number of threads started at 1 point in time over the period (could
add a checkbox to the GUI to specify Final Concurrent instead of total
number over test duration?
The calculation shouldn't be too complex, and it could be nice to have this
feature to simulate increasing load.
Thoughts on this?
If all the threads last long enough, then the current ramp-up time
will work as you want.
However, if the first threads finish before the last threads start,
then of course the number of concurrent threads at the end of the
ramp-up will be less than the total number of threads.
Regardless of how the threads are started, if the first threads don't
last long enough, then the number of active threads at the end of the
ramp-up will be less than the total.
-
To unsubscribe, e-mail: jmeter-dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-h...@jakarta.apache.org
