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 13:33:40 GMT
What is your view on how to go forward then?

  To let "functional test mode" also mean that the samples
  are collected in a batch after the completion of the test ?


  to introduce a new checkbox on the TestPlan pane that allows
  you to specify if the server is to hold on to the samples until
  the end of the test-run?



Regards Lasse

-----Original Message-----
From: []
Sent: den 7 oktober 2003 15:21
To: JMeter Users List
Subject: RE: JMeter remote test performance problems?

This was kind of the intent behind the "functional test mode" 
checkbox.  Just never fully implemented.


On 7 Oct 2003 at 8:29, Lars-Erik Helander wrote:

> 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
> to
> 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
> ...
> Regards
> 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...
> S.
> -----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 
> for this communication, is well known for not being "nice" to 
> it will probably very well explain the behavior. Still I very mich 
> the JMeter capabilities in distributed mode, where the collection 
> results from the server instances is done by the controlling 
> I changed the source code slightly so that a JMeter server did 
> 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: []
> 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 
> can look at:
> 1. save to csv format rather than xml.   Results in a lot less 
> 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.  
> you can view your data in a spreadsheet.
> 2. Turn off functional testing (in the Test Plan element) if you 
> it on.  This will cause all server data to be written to the file which 
> 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 
> these same issues plus firewall problems since I work from 
> Run all the jmeter instances separately and non-gui, saving data 
> csv files.  When all are done, merge the csv files and view in
> jmeter (again, get a recent nightly).  The important thing here is 
> start and stop all the instances are around the same time.  You 
> schedule them, but the scheduler is extremely inconvenient to 
> and a bit flaky (not it's fault, java seems to lose track of threads 
> sleep for hours at a time).  I do these things manually and with 
> 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 
> 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 
> machines
> > in  I've created a simple test plan consisting 
> 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 
> > configuration described above, it gets pegged at 99% CPU
> utilization until
> > the test is finished.  I've tried playing with the number of 
> 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 
> 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 
> 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 
> 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 
> > 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 
> 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 
> disk?
> > Is something else going on?  Is it just the case that the 
> 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 
> 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: jmeter-user-
> For additional commands, e-mail: jmeter-user-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-
> For additional commands, e-mail: jmeter-user-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-
> For additional commands, e-mail: jmeter-user-
> ---------------------------------------------------------------------
> 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:

View raw message