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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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- > [EMAIL PROTECTED] > > For additional commands, e-mail: jmeter-user- > [EMAIL PROTECTED] > > > > > > > -- > Michael Stover > [EMAIL PROTECTED] > Yahoo IM: mstover_ya > ICQ: 152975688 > AIM: mstover777 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user- [EMAIL PROTECTED] > For additional commands, e-mail: jmeter-user- [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user- [EMAIL PROTECTED] > For additional commands, e-mail: jmeter-user- [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user- [EMAIL PROTECTED] > For additional commands, e-mail: jmeter-user- [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user- [EMAIL PROTECTED] > For additional commands, e-mail: jmeter-user- [EMAIL PROTECTED] > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
