jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars-Erik Helander" <helan...@gatespacetelematics.com>
Subject RE: JMeter remote test performance problems?
Date Sat, 04 Oct 2003 14:04:48 GMT
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.

Regards

Lasse Helander

-----Original Message-----
From: mstover1@apache.org [mailto:mstover1@apache.org]
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.

-Mike

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
control
> 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
2.4.20-20.9,
> with the Sun 1.4.2_01 JRE.  remote_hosts is set to the three test
machines
> in jmeter.properties.  I've created a simple test plan consisting of
a
> 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
writer
> listener.  The machines are all on a switched LAN.
>
> The main problem with the setup is that the test controller can't
handle
> 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
and
> ramp up period a little, but I can't generate reasonable load on
the
> 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
configuration,
> the test controller sees about 230-300K/s of traffic, and the server
only
> gets about 80-120K/s and about 4-8% CPU load.
>
> I tried running jmeter in console mode (jmeter -n -r -t
simpletest.jmx),
> but kept running into some sort of OutOfBoundsException (sorry,
I don't
> have the stack trace with me at the moment) in an Apache
collections
> 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
used.
>
> 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
disk?
> Is something else going on?  Is it just the case that the remoting
in
> jmeter is too chatty?  What can I do to stop the test controller
from
> 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-
unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-
help@jakarta.apache.org
>




--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

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


---------------------------------------------------------------------
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