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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
