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
