jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barrie Treloar <baerr...@gmail.com>
Subject Re: determining ramp-up period
Date Thu, 23 Jun 2011 12:57:07 GMT
On Thu, Jun 23, 2011 at 8:31 PM, sebb <sebbaz@gmail.com> wrote:
> On 23 June 2011 11:06, Kirk <kirk.pepperdine@gmail.com> wrote:
>> One has to really be careful with JMeter's threading model. It has the potential
to act as the bottleneck in your load test. I've seen a few teams chasing all kinds of things
in the app server when they really needed to be looking at what was coming behind them. IMHO,
a thread per user is an easy model to grasp but is much easier to set yourself up for failure.
Case in point, and earlier suggestion that if the response times are greater than the desired
rate of arrival at the server, the throughput will drop 'cos JMeter will simply not have enough
threads to trigger the request. Hence, the bottleneck in the system will be JMeter. While
some might argue that this is sill ok (and in a number of cases it's not harmful), an event
based model would be much more scalable and less prone to this type of testing failure.. artificial
throttling of throughput.
>
> If I understand you correctly, what you are saying is that the maximum
> throughput for a single JMeter thread is limited by the response time
> of the server, because JMeter waits for the sample to complete before
> issuing the next request.
>
> Have I got it right?

I think what he is saying is that if you have use a constant
throughput controller set to say 10, i.e. 1 every 6 seconds,
but each response takes 12 seconds, then you only get a throughput of
5 because missed "optimal boundaries" for transaction per minute
aren't "caught up".
1 can be missed, it will give you a delay of zero, but if two are
missed then the first delay is still zero, but where the second delay
should also be zero (since its not meeting throughput yet) it will
instead be
targetTime - previousTime.

Constant Throughput Controller doesn't do "average" transactions per
minute.  Either it runs instantly, or you wait until the next "optimal
boundary" (i.e. up to msPerRequest)
Hence your load is artificially lower.

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message