jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mstov...@apache.org
Subject RE: JMeter remote test performance problems?
Date Tue, 07 Oct 2003 14:06:59 GMT
I would like to see a dialog box give a bunch of options when starting a remote 
server.  If I want to start a remote server, a dialog pops up and I can choose the 
threadgroups that go over, I can set the values of some user-defined variables 
specific for that server, I can specify whether it's to run in functional mode or not, 
whether the results are to be saved to a local file or send interactively during the 
run, or all at the end, etc....

Then, I want to save those settings and let the user just click a button to run that 
server with those settings any time.

Heh, but then, I'm a dreamer.

-Mike

On 7 Oct 2003 at 15:33, Lars-Erik Helander wrote:

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




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


Mime
View raw message