Navigation trail: JMeterProjectPages - JMeterDevelopment - JMeterDevelopment/LongTerm

How can we improve the remote testing experience?

RMI/Firewall issues

In the list above are some points regarding firewall configuration and the need for tunneling RMI through a firewall. To make these requirements more clear can anyone please give an example of why it is necessary to use a remote JMeter server BEHIND a firewall and why it is not possible in that situation to use a JMeter server IN FRONT of the firewall. -- OliverRossmueller

Because the firewall is placed between the admin network (where I'm sitting) and the production network (where the servers are). Of course there are other solutions, such as running JMeter GUI on the production network displaying on my screen through an X tunnel -- but these are often undesirable (because of latency/bandwith limitations) or impossible (because some machines don't support X). This is nothing weird nor unusual, I'd say I'd find myself in such situation in 70-80% of the large customers I visit -- JordiSalvat 2003-08-11.

I noted the firewall issues when I was doing something a little weird - using a win2k box to control a JMeter server on a Mac OS X box with it's firewall running (even though it was on the internal network). The Mac is a laptop and so it is sometimes connected directly to the net, hence the local firewall. -- ScottEade 2003-01-16

A different example might be that you have a bunch of JMeter server machines on an internal network somewhere that you want to control from a physically remote machine that is on an external network - this is a contrived example as it would require effort to make the JMeter server machines visible outside the firewall. -- ScottEade 2003-01-16

All in all it is nothing like the issue I originally imagined it to be. -- ScottEade 2003-01-16

a modified version

re remote testing and firewall issues, just modified jmeter source based on v2.1.1. with the modification, a new property 'server.service.port' could be used for the jmeter service port (pls note this is different from the rmi registry port which could also be configured by 'server.rmi.port') in current jmeter release uses a random port number which may cause some trouble for sysadmin to adjust firewall rules (especially if you sysadmin is very much concerned about any potential security issues). so you could give jmeter a static port number for the service and let sysadmin know the port as well.

* if you only need binary (working copy), download ApacheJMeter_core.jar which is recompiled with my change; and as an option, feel free to download new

* for source code, pls download two patches, one for src/core/org/apache/jmeter/engine/ and the other for bin/ simply apply them and job done.

(I have been looking for any chance contribute that modification back to main development tree, so feel free to use it if it could be included in a future release)

-- ChenWang 2006-01-12

The above changes have been applied to the code - see Bug 30379

Remote Testing Set Up using Rendezvous

It would be really nice to use some of the ZeroConf technology that is become more and more proliferate now to automatically discover the remote servers available to control on a network. I know there is a module called JRendezvous which is an implementation of Rendezvous (Apple's brand name for ZeroConf) that could be used. Imagine how nice it would be to run up your remote servers, then click a menu in your client GUI and automatically see the various remote servers that are avilable. Its one last thing to fight with when trying to get this set up. Also looks a little more polished. ...although, saying this, it may be more useful if the GUI could cut and paste nodes first (let's run before we can walk) -- Craig Pugsley 12/3/03

Remote Testing Set Up

Would it be feasible to have the remote server "push" its IP address to the controlling client?


At present, when a script is sent to the remote server for execution, AFAIK the entire tree is serialised and reconstructed at the other end. This places a lot of burden on developers to make sure that objects are serialisable. Since there is already a convenient representation for a test (i.e. the JMX format) it seems to me that we should make use of it and ship that across instead. It would mean that the remote installation would need to have all the appropriate classes present, but that is probably true anyway. It should reduce the amount of data sent. It would probably get rid of some of the incompatibilities that occur. I read somewhere recently (probably Effective Java by Joshua Bloch) that hash values are not _guaranteed_ to be the same for different JVMs, nor even between runs of a JVM, which might explain some problems users have reported.sebb

Similar considerations apply to the Sample data that is returned, and it would be useful to be able to batch this and/or just send back aggregrate data during a test run, and allow the client to request the full data when required.

JMeterRemoteTestingEnhancements (last edited 2010-10-05 01:15:31 by 182ob)