jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Cysne <flaviocy...@gmail.com>
Subject Re: Ramp up period doesn't correspond to duration of test
Date Tue, 01 Oct 2013 19:03:38 GMT
2000 threads within 4 seconds, in JMeter, means that in 4000 milliseconds
it'll have started all 2000 threads.
Just do this calculation <Number of Threads> / <Ramp up time in
milliseconds> = <Number of threads started at each unit of time>
In your case it'll be 2000 threads / 4000 milliseconds and so 1 thread at
each 2 milliseconds.

Other thing is that Ramp-up is not the time your script will be running.
It'll be running until each of all threads, after it starts, has got its
response.

In distributed testing you have to add <Number of JMeter slaves> to the
equation.
<Number of JMeter slaves> * <Number of Threads> / <Ramp up time in
milliseconds> = <Number of threads started at each unit of time>


2013/10/1 Robert Taylor <robertt@rtnetworks.com>

> Hi all,
>
>
>
> I'm new to JMeter and ran several tests against our website over the
> weekend
> using HTTP.  We configured our tests to use a CSV file to populate
> variables
> within our test and ran our test starting with a thread count of 25 users
> and slowly increased the number of threads until we reached 2,000.  Our
> ramp
> up time was 4 seconds, which according to the documentation looked like we
> would have divided the ramp up time by the number of users, i.e., 4
> secs/100
> users would have mean 25 users per second.
>
>
>
> I realize that it probably wasn't realistic to think 1,000 users/http
> requests could be initiated in 4 seconds, but how does JMeter determine how
> many users to launch simultaneously?  My goal was to attempt to break our
> system by finding the number of users at which point our server would
> crash.
> Instead, the more threads I used, the longer the total script took to run.
> This doesn't seem to correspond to the JMeter docs for the ramp up time.
>
>
>
> Any help would be appreciated.
>
>
>
> Trebor
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message