Distributed testing is to be used when you reach the limits of a machine in terms of CPU, Memory, Network. Distributed testing is a kind of testing which use multiple systems to perform stress testing. It's applied for testing web sites and server applications when they are working with multiple clients simultaneously.
Few checkpoints before getting started with distributed testing:
1. the firewalls on the systems are turned off.
2. all the clients are on the same subnet.
3. the server is in the same subnet, if 192.x.x.x or 10.x.x.x ip addresses are used. If the server
doesn't use 192 or 10 ip address, there shouldn't be any problems.
4. Make sure JMeter can access the server.
5. Make sure you use the same version of JMeter on all the systems. Mixing versions may not work
correctly.
Once you've made sure the systems are ready, it's time to setup remote testing.
Terms we are using:
- Master: the system running JMeter GUI, control each slave.
- Slave: the system running jmeter-server, receive command from the master and send a request to server under test.
- Target: the web server under test, get request from slaves.
Steps: -
1. On the slave systems, move to jmeter/bin directory and execute jmeter-server.bat (jmeter-server on
unix). On windows, you should see a dos window appear with “jre\[version]\bin\rmiregistry.exe”.
If this doesn't happen, it means either the environment settings are not set or there are
multiple JRE installed on the system.
To correct the settings, please follow the given steps:
1. Open 'jmeter-server.bat' in a text editor
2. go to line 44 and find “:setCP”
3. edit “START rmiregistry” to the full path. Example: “START C:\<JAVA_HOME>\jre\bin\rmiregistry”
4. Save the batch file and restart 'jmeter-server.bat'.
2. On master system acting as the console, open windows explorer and go to jmeter/bin directory
3. Open jmeter.properties in a text editor
4. Edit the line “remote_hosts=127.0.0.1”.
5. Add the IP address of slave machines. For example, if I have jmeter server running on 192.168.0.10, 11, 12, 13, and
14, the entry would be like this:
remote_hosts=192.168.0.10,192.168.0.11,192.168.0.12,192.168.0.13,192.168.0.14
6. Start jmeter.
7. Open the test plan you want to use
Starting the Test
At this point, you are ready to start load testing. If you want to double check the slave systems are
working, open jmeter.log in notepad. You should see the following in the log.
Jmeter.engine.RemoteJMeterEngineImpl: Starting backing engine
If you do not see this message, it means jmeter-server did not start correctly. For tips on debugging
the issue, go to the tips section.
There are two ways to initiate the test:
1) Remote Start
2) Remote Start All.
Both options are listed under 'Run' option.
Like this:
Limitations:
There are some basic limitations for distributed testing. Here's the list of the known items in no specific order.
1. RMI cannot communicate across subnets without a proxy; therefore neither can jmeter without a proxy.
2. Since JMeter sends all the test results to the controlling console, it is easy to saturate the
network IO. It is a good idea to use the simple data writer to save the results and view the file
later with one of the graph listeners.
3. Unless the server is a large multi processor system, in most cases 1-2 clients is sufficient to
overwhelm the server.
4. A single JMeter client running on a 2-3Ghz CPU(recent cpu)can handle300-600 threads depending on the type of test.(The exception is the webservices). XML processing is CPU intensive and will rapidly consume all the CPU cycles. As a general rule, the performance of XML centric applications will perform 4-10 slower than applications using binary protocols.
Few checkpoints before getting started with distributed testing:
1. the firewalls on the systems are turned off.
2. all the clients are on the same subnet.
3. the server is in the same subnet, if 192.x.x.x or 10.x.x.x ip addresses are used. If the server
doesn't use 192 or 10 ip address, there shouldn't be any problems.
4. Make sure JMeter can access the server.
5. Make sure you use the same version of JMeter on all the systems. Mixing versions may not work
correctly.
Once you've made sure the systems are ready, it's time to setup remote testing.
Terms we are using:
- Master: the system running JMeter GUI, control each slave.
- Slave: the system running jmeter-server, receive command from the master and send a request to server under test.
- Target: the web server under test, get request from slaves.
Steps: -
1. On the slave systems, move to jmeter/bin directory and execute jmeter-server.bat (jmeter-server on
unix). On windows, you should see a dos window appear with “jre\[version]\bin\rmiregistry.exe”.
If this doesn't happen, it means either the environment settings are not set or there are
multiple JRE installed on the system.
To correct the settings, please follow the given steps:
1. Open 'jmeter-server.bat' in a text editor
2. go to line 44 and find “:setCP”
3. edit “START rmiregistry” to the full path. Example: “START C:\<JAVA_HOME>\jre\bin\rmiregistry”
4. Save the batch file and restart 'jmeter-server.bat'.
2. On master system acting as the console, open windows explorer and go to jmeter/bin directory
3. Open jmeter.properties in a text editor
4. Edit the line “remote_hosts=127.0.0.1”.
5. Add the IP address of slave machines. For example, if I have jmeter server running on 192.168.0.10, 11, 12, 13, and
14, the entry would be like this:
remote_hosts=192.168.0.10,192.168.0.11,192.168.0.12,192.168.0.13,192.168.0.14
6. Start jmeter.
7. Open the test plan you want to use
Starting the Test
At this point, you are ready to start load testing. If you want to double check the slave systems are
working, open jmeter.log in notepad. You should see the following in the log.
Jmeter.engine.RemoteJMeterEngineImpl: Starting backing engine
If you do not see this message, it means jmeter-server did not start correctly. For tips on debugging
the issue, go to the tips section.
There are two ways to initiate the test:
1) Remote Start
2) Remote Start All.
Both options are listed under 'Run' option.
Like this:
Limitations:
There are some basic limitations for distributed testing. Here's the list of the known items in no specific order.
1. RMI cannot communicate across subnets without a proxy; therefore neither can jmeter without a proxy.
2. Since JMeter sends all the test results to the controlling console, it is easy to saturate the
network IO. It is a good idea to use the simple data writer to save the results and view the file
later with one of the graph listeners.
3. Unless the server is a large multi processor system, in most cases 1-2 clients is sufficient to
overwhelm the server.
4. A single JMeter client running on a 2-3Ghz CPU(recent cpu)can handle300-600 threads depending on the type of test.(The exception is the webservices). XML processing is CPU intensive and will rapidly consume all the CPU cycles. As a general rule, the performance of XML centric applications will perform 4-10 slower than applications using binary protocols.
