THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Wiki Markup
...
How can we improve the remote testing experience?
- Documentation of remote testing does not provide details of the ports that need to be open on a firewall
- Make remote testing easier and less error prone (provide shell scripts for rmiregistry or do not use RMI at all) – OliverRossmueller 2003-01-06
- The very first thing we should do is to update the jmeter-server scripts to set the classpath and start rmiregistry before starting jmeter. – ScottEade 2003-01-07
- Need a solution for tunneling RMI through a firewall (publicly available solutions exist). – ScottEade 2003-01-05
- Option to specify the port to be allocated by rmi. – ScottEade 2003-01-05 I just can't understand any situation where running JMeter remotely through a firewall is necessary or desirable. I can only think that people who insist on being able to do this have a fundamental misunderstanding of what a remote JMeter "server" is for - MikeStover _ Situation: I want to run the jmeter GUI from my desktop in our local network, but test an internal service in our data center. The remote jmeter slaves and our server need to be in the data center network to simulate real usage (The users of this service are internal). If I ran the tests from my local network there would be extra latency and it would not give me realistic numbers. - MikeDeeks_)
- The ability to easily configure a set of remote testing hosts with varying parameters (number of threads to cater for testing hosts of varying capacity, counter values to handle things like ensuring user identifiers are unique across all test hosts) so that it is easier to initiate distributed testing from multiple remote hosts. – ScottEade 2003-01-07
- Ensure relevant items can be set using variables.
- Allow parameters to be specified on a per server basis (much like User Parameters), perhaps these would replace the User Defined Variables on the Test Plan element.
- Would want a checkbox to indicate which servers should be active for a test run (this would effectively define a single set of hosts, the members of which can be very easily updated).
- Could enter the address of the server here and eliminate the remote_hosts setting in jmeter.properties.
- Good thoughts - maybe a dialog box could provide a bunch of controls associated with starting a remote host - ie IP address, custom user-defined variables for that run, etc.
- Pass properties specified via jmeter -Jvariable=value through to remote servers. It took embarrassingly long for me to realize that if I pass -J properties on the command line and don't run with -r, the properties are set correctly for the local instance, but if I do pass -r, none of the remote servers see the property specified on the command line (they always get the default value). --ChrisNuzum 2006-10-18
- I also took a long time to resolve this issue... On the client, code -Jmygroup.threads=10 and -Gmygroup.threads=10. -G parameters get passed to the server. --Dave Bruce 2009-12-10
- Provide a simple way to make a counter work with multiple machines. A lot of use cases the only data that needs to be changed is the usernames and deploying a csv file and all is unnecessary and inconvenient. I've actually written a component that would do this, but the number of servers being used and an index in the list are required to do this properly. Should be very easy to do this when initializing engines. just define two more standard test variables in each engine as created (Sean Ferguson email at sean.d.ferguson@att.net)
...
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
...
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 jmeter.properties. 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 \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/ApacheJMeter_core.jar\] which is recompiled with my change; and as an option, feel free to download new jmeter.properties \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/jmeter.properties\].
\\
Wiki Markup
(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
...
– KeivnHurley 01/27/2005
...
Serialisation
...
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.