How to do remote testing the 'proper way'?

Interview Questions

Apache JMeter FAQ

How to do remote testing the 'proper way'?

You have:
1. Your application server. You shouldn't run anything on this machine that you wouldn't have running on it in your proposed or actual production environment (if you are running anything else, including JMeter, you will be adding load to the server and thus tainting your results).

2. One or more machines running jmeter-server (the JMeterEngine). You want these machines to be reasonably close (network wise) to the application server. By "reasonably close" I mean on the same Ethernet segment or at least with no low speed links between them. The JMeter User Manual provides reasonable information about doing this.

3. A single machine running the JMeter GUI that you use to control the machines running the JMeterEngine.
While you are developing your scripts and for only moderate levels of user testing (assuming you are "close" to the application server) you do not need to involve any JMeterEngine machines. The reason you have these are to:
1. Eliminate the impact of slow network connections when you are not "close" to the application server.
2. Execute more test threads than your local machine is capable of handling.

Note that if the GUI is running multiple remote servers, it can easily become a bottle-neck, especially if a lot of listeners are being used. Remove all unnecessary listeners before running stress tests.

Running JMeter in non-GUI (batch) mode is preferable, as this uses far fewer resources. The output log files can be merged after the test run and used to create overall test statistics. (CVS files can just be appended to each other; XML output files need a bit of editting to maintain well-formedness.)

If there are several nodes running the JMeter test plan, it is a good idea to try and ensure that their clocks are synchronised, as this makes it easier to analyse the data later.

(Continued on next question...)