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