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

  OR 

  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?

  OR

  ...

Regards Lasse

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

-Mike

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 
[mailto:Sebastian.BAZLEY@london.sema.slb.com]
> 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 
[mailto:helander@gatespacetelematics.com]
> 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.
> 
> 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
> 
> ---------------------------------------------------------------------
> 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
> 




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