jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars-Erik Helander" <>
Subject RE: JMeter remote test performance problems?
Date Tue, 07 Oct 2003 06:29:08 GMT
I agree that the easiest way to control would be a property valid for the
whole server engine.

During the initial phases of running a test, it is very
nice to see the results in "real-time" so that you can "validate" that the
test are performing as could be exepected. When this is done you would like
apply "full" load and then analyze the result. It would be very nice to be
able to
do this change of mode on the server, without having to restart the server.

We are looking into how to set this property per test plan
(and even per thread group). We will work with this the next couple of weeks

Lasse Helander

-----Original Message-----
From: BAZLEY, Sebastian []
Sent: den 6 oktober 2003 16:22
To: 'JMeter Users List'
Subject: RE: JMeter remote test performance problems?

Sounds a very useful enhancement. [It could certainly help us, as our test
systems are separated from our desktops by a WAN link ... so we have to use
batch mode]

I think the easiest (at least initially) would be to control this via a
jmeter property, which can be put into the properties file or defined on the
command line when starting the server.

Perhaps you could post your code / patch to Bugzilla?
We can then add the property check as necessary...

-----Original Message-----
From: Lars-Erik Helander []
Sent: 04 October 2003 15:05
To: JMeter Users List
Subject: RE: JMeter remote test performance problems?

My interpretation of the core problem here is that all samples
are reported back to the controlling JMeter instance in "real-time".
This slows down the sampling process and since RMI, that is used
for this communication, is well known for not being "nice" to performance
it will probably very well explain the behavior. Still I very mich like
the JMeter capabilities in distributed mode, where the collection of
results from the server instances is done by the controlling instance.

I changed the source code slightly so that a JMeter server did locally
store all samples during a test-run,and at the end of the test-run
it reported all stored samples to the controlling instance. It worked
very nicely.

I think that this or a similar approach is much better than having
to externally move and merge a number of csv or xml files.

How this functionality fit together with the rest of the
JMeter architecture, is for the JMeter experts to tell, but
I think it would be a much better way from the users point
of view.

If this behavior is to be controlled by the server instances
(parameter to start of JMeter in server) or by some
entity in the test plan is an open issue. You have to
be more familiar than me with the JMeter implementation in order
to fully understand the implications of various alternatives, so
I hope someone with this knowledge are willing to discuss/explore
this further.


Lasse Helander

-----Original Message-----
From: []
Sent: den 27 september 2003 00:43
To: JMeter Users List
Subject: Re: JMeter remote test performance problems?

JMeter's remote feature is a bit broken because the controlling
machine ends up being a bottleneck as you say.  Some things you
can look at:

1. save to csv format rather than xml.   Results in a lot less writing
to the file.  Unfortunately, jmeter 1.9.1 can't read in csv files, but
the latest JMeter code can, and 1.9.2 will be able to as well.  Also,
you can view your data in a spreadsheet.

2. Turn off functional testing (in the Test Plan element) if you have
it on.  This will cause all server data to be written to the file which My
could potentially be an enormous amount of data.

3.  Remove all listeners except Aggregate Report.

If these don't help or aren't your problem, then do what I do (I have
these same issues plus firewall problems since I work from home):
Run all the jmeter instances separately and non-gui, saving data to
csv files.  When all are done, merge the csv files and view in
jmeter (again, get a recent nightly).  The important thing here is to
start and stop all the instances are around the same time.  You can
schedule them, but the scheduler is extremely inconvenient to use
and a bit flaky (not it's fault, java seems to lose track of threads that
sleep for hours at a time).  I do these things manually and with shell
scripts to help me out.


On 25 Sep 2003 at 20:02, Alfred Freur wrote:

> I'm new to JMeter, so please forgive me if this is an old question.  I've
> read the FAQ, the User Manual, and searched the mailing list archive, but
> I may have missed something obvious.
> I've been trying to set up JMeter to do a distributed load test
using some
> "repurposed" desktops.  I've started out with a simple test plan to
try to
> familiarize myself with the program, and I've run into a few
problems I
> can't seem to fix.
> First, the setup: I have a "server" running the web app, a test
> machine running jmeter, and three additional test machines
running the
> jmeter-server script (had some problems with that, but fixed
them).  All
> the machines are running JMeter 1.9.1 on Red Hat 9, kernel
> with the Sun 1.4.2_01 JRE.  remote_hosts is set to the three test
> in  I've created a simple test plan consisting of
> thread group (50 threads, 30s ramp-up, 100 loops), an HTTP
sampler doing a
> simple get against a servlet on the server, and the simple data
> listener.  The machines are all on a switched LAN.
> The main problem with the setup is that the test controller can't
> the load, and ends up being the bottleneck for the test.  With the
> configuration described above, it gets pegged at 99% CPU
utilization until
> the test is finished.  I've tried playing with the number of threads
> ramp up period a little, but I can't generate reasonable load on
> server before the test control machine gets swamped.  It's an
Athlon 2000+
> with a gig of RAM, so I have some reason to expect it to be able
to handle
> this load.  It may also be worth mentioning that in this
> the test controller sees about 230-300K/s of traffic, and the server
> gets about 80-120K/s and about 4-8% CPU load.
> I tried running jmeter in console mode (jmeter -n -r -t
> but kept running into some sort of OutOfBoundsException (sorry,
I don't
> have the stack trace with me at the moment) in an Apache
> class, which caused only one (the last) of the remote testing
machines to
> be used for the test.  This of course reduced the load on the test
> controller (to about 30% CPU usage), but didn't really put any
load on the
> server at all, as two of the remote test machines weren't being
> I'm not really familiar with JMeter as a user, and I haven't looked
at the
> code at all; is there something that I might have misconfigured
that could
> lead to such a high load to just collect samples and write them to
> Is something else going on?  Is it just the case that the remoting
> jmeter is too chatty?  What can I do to stop the test controller
> being the bottleneck, short of buying a 16-way machine?
> I appreciate any suggestions that anyone can offer.  JMeter looks
like a
> great piece of software, and I'd like to make it work!
> --
> Alfred Freur
> Software Engineer
> Contrado Partners, LLC
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-
> For additional commands, e-mail: jmeter-user-

Michael Stover
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message