jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Goel <deic...@gmail.com>
Subject Re: constant rate testing (again)
Date Tue, 27 Jul 2010 20:57:51 GMT
Hey

Namaskara~Nalama~Guten Tag

Just another though to this:

If your load is reaching the servers, looks like the max load which your
server system can handle is that of one Jmeter server. When you add more
servers, the throughput will reduce as the max throughput of the system has
already been reached. After the max throughput has been reached, if you
increase the load, the throughput starts dropping as your server cannot
handle so many concurrent sessions simultaneously creating an overhead on
the execution of all the request in the system.

For any system, you have to know what is the max throughput which it can
achieve beyond which the response time starts increasing exponentially. The
throughput then reaches a plateau, and if you increase the load further the
throughput would start decreasing and the system might even crash.

I guess thats what happens in real world scenarios too. For example: In
normal shopping periods, the system is able to manage the real user load
with reasonable response times. During festive times, the system gets too
drained out with the incoming request, and the response time increases
exponentially. This causes a constant throughput and sometimes even the
system to crash.

Did you try this option?
*****************************************************
Or is all of this complicated setup == a
> large thread group + long ramp up period?
*****************************************************
Deepak

   --
Keigu

Deepak
+91-9765089593
deicool@gmail.com

Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com
Facebook: http://www.facebook.com/deicool

Check out my Work at:
LinkedIn: http://in.linkedin.com/in/thumsupdeicool

"Contribute to the world, environment and more : http://www.gridrepublic.org
"


On Tue, Jul 27, 2010 at 9:33 AM, Deepak Goel <deicool@gmail.com> wrote:

> Hey
>
> Namaskara~Nalama~Guten Tag
>
> Is the load reaching the servers from the other machines? Looks like only
> the first machine load is able to reach the servers.
>
> Deepak
>    --
> Keigu
>
> Deepak
> +91-9765089593
> deicool@gmail.com
>
> Skype: thumsupdeicool
> Google talk: deicool
> Blog: http://loveandfearless.wordpress.com
> Facebook: http://www.facebook.com/deicool
>
> Check out my Work at:
> LinkedIn: http://in.linkedin.com/in/thumsupdeicool
>
> "Contribute to the world, environment and more :
> http://www.gridrepublic.org"
>
>
>
> On Tue, Jul 27, 2010 at 2:02 AM, William Oberman <oberman@gmail.com>wrote:
>
>> Well, this is weird/irritating.  No matter what I do I can't create
>> more than certain amount of load with JMeter.  For example, if I run
>> one server at full throttle, I might get 75 req/sec.  If I run two
>> servers with the same size thread pool, I then get ~37 req/sec.  If I
>> run three servers with the same size thread pool, I get 25 req/sec.
>> And so on.
>>
>> I guess this problem is more complicated than I thought without Jmeter
>> having a specific feature to generate constant inbound load (or
>> dropping connections slower than X seconds, which I think would also
>> work)
>>
>> will
>>
>> On Mon, Jul 26, 2010 at 1:40 PM, William Oberman <oberman@gmail.com>
>> wrote:
>> > I found an old email thread about doing constant rate testing in the
>> > archives.  I wanted to kick the idea up again, but first I'll review
>> > the basic situation, and past advice:
>> > -I want to simulate a constant inbound rate, so that if the server
>> > falls behind the inbound load keeps coming and crushes the server
>> > -Jmeter has a fixed pool size + every thread waits for a response, so
>> > jmeter will in effect "slow down to accommodate" the load
>> > -The advice from the old thread (my interpretation) was basically find
>> > a thread pool size large enough to crush the server
>> >
>> > The "next step" problem the user in the old thread appeared to be
>> > having was the inability to scale Jmeter to "crushing load" levels.  I
>> > don't have that problem... I can create thread pools that create
>> > crushing load.  But, I'd vastly prefer to create the real world use
>> > case of constant inbound load.  I was wondering if there is a clever
>> > use of the Constant Throughput Timer (CTT) that will help?
>> >
>> > I haven't used the CTT much before, but based on the description, it
>> > seems promising.   My basic idea was going to be:
>> > -Have a thread group with size greater than the "crushing level"
>> > -Use the CTT (or CTTs) to throttle the huge thread pool to keep most
>> > threads idle
>> > -As the server experiences load and slows down, the CTTs will continue
>> > to let previously idle threads run (to keep the rate at a certain
>> > level), hopefully slowing increasing the load to the crushing point
>> >
>> > I'm obviously still playing around, trial and error style.  But, I
>> > thought I'd check here in case there is a fundamental flaw I'm missing
>> > (or an easier approach).  Or is all of this complicated setup == a
>> > large thread group + long ramp up period?  I'll try that too...
>> >
>> > will
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>

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