jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Speteanu <>
Subject Re: Odd problem with performance of JMeter
Date Tue, 28 Jun 2011 11:11:48 GMT
Hello all,

John, Sorry to bargin on the discussion mid-way, from your first description
of the problem, I wonder if you are running JMeter by using the "jmeter"
script (for linux) or jmeter.bat (for windows).

I have a graph of a benchmark that emphasizes exactly what you have
described in your initial mail. This is what happened when I ran a synthetic
benchmark that doesn't depend on an external application:
  * throughput:
  * response times:
Why? Because I ran JMeter just by executing the ApacheJMeter.jar without
tweaking anything. And the response times are so stable! Java Virtual
Machine selftunes for long-term stability and efficiency, not performance,
unless performance is specifically required of it.

This is what happens when running the same test, but JMeter is started with
jmeter.bat (on Windows XP, in the case of these tests/graphs):
  * throughput:
  * response times:

Big difference right?
(the test ran 1000 threads in both cases on a dual-core, 2Gb RAM desktop
system with Windows XP / Ubuntu 10.04)

This is about java, not JMeter (and on linux it gets even more "fun", a lot
more fun). Also, I got pretty stable results running with a tone of
listeners in GUI mode (because the purpose of the test script was to use a
lot of CPU and RAM, a lot more than what is recommended during tests). Note
that you will encounter fluctuations in non-GUI mode as well, unless you
have a minimum of configuration.

Hope this helps, a lot of folks just ask if this is because of JMeter. When
using a throughput timer / controller you force the application to take more
load (even if it can't handle it in a stable manner) - this will reflect in
response time growing and growing.

If you're in one of the situations: throughput decreasing (with response
times relatively stable) or response times increasing (with throughput
relatively stable) than you should consider that either the client or the
application is bottlenecked by ...uhm... something (looooong topic) - its
usually the application under test. When you can't get too much out of one
JMeter just add more with smaller loads (even on one single machine), the
last thing you want to worry about is that the test client is not performing

Best wishes,
Adrian S

On Fri, Jun 24, 2011 at 7:13 PM, John Lussmyer <>wrote:

> Using the Active Thread only setting, and running 10 threads got me a
> pretty even distribution of requests.
> What I've found odd is that it's hard to reproduce any one test, and get
> results that are even kind of similar to the previous test.
> At very light loads, everything reproduces nicely.
> At even medium loads, I start getting weird results.  Things like the
> server (and JMeter) system seems to start "pulsing" on about 20 second
> intervals.  Handles a burst of requests, then massively slows down.  And
> it's CPU usage drops during the pauses, memory usage is pretty constant, not
> much disk activity.
> Just weird. (probably a problem in our code, so it's giving us something to
> hunt for.)
> The non-reproducible part is that I run a test at a medium load, and it
> works fine, good response, etc...
> 10 minutes later I run the same test, and it goes into pulse mode, response
> times go up by a factor or 10 or more.
> This is on a dedicated server.
> -----Original Message-----
> From: Oliver Lloyd []
> Sent: Wednesday, June 22, 2011 3:09 PM
> To:
> Subject: Re: Odd problem with performance of JMeter
> Try this:
> Thread Group - 1 user, 1 sec ramp, forever
> ---->Dummy Request, 1 sec response time
> ---------> Constant Throughput Timer, Active Thred Only, 10 reqs per minute
> Like this you get 1 request every 6 seconds, nice and steady.
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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