Distributed testing in Jmeter

You have reached the limit of one machine while doing your load testing and now want to distribute your load from different machines. In Jmeter it is commonly called as distributed load testing or remote testing.

Distributed testing or remote testing have 3 parts: JMeter Master, JMeter Slaves and Target.

Following figure explains the relationship between them.




Distributed setup prerequistie

1. All firewalls in JMeter master and slave machines should be turned off

2. All machines should be in same subnet

3. Use same version of JMeter in all machines( master and slaves)


Setting up the environment

Setup consists of  3 parts:

Master – running the JMeter GUI/command which controls the test

Slave – the system running the JMeter server, which takes command from the GUI/master and send request to the Target system.

Target – The web server which is to be load/stress tested.

Slave configuration

Make sure jmeter-sever.bat have proper path to rmiregistry.

Master Configuration

  • Open jmeter.properties and edit the line “remote_hosts=”.
  • Add IP address of the slave machines e.g.: “remote_hosts=,,192.168.8”


Starting the Distributed test

  • Start jmeter-server.bat in all slave machines
  • Start jmeter.bat in master machine and open the test plan to run. Use remote start or remote start all option from the menu. Alternatively, you can use command prompt to run the test script as shown below.

jmeter -n -t my_test.jmx -l log.jtl –r

-n this specifies JMeter is to run in non-gui mode

-t [name of JMX file that contains the Test Plan].

-l [name of JTL file to log sample results to].

-r Run all remote servers specified in jmeter.properties (or remote servers specified on command line by overriding properties)

Results Visualization using xsl stylesheet in JMeter

Using xsl stylesheet in JMeter with .jtl files

Jmeter provide several .xsl files to visualize the result in human readable format outside JMeter tool.
These are located in %APACHE_JMETER_HOME/extras folder

  • jmeter-results-detail-report.xsl
  • jmeter-results-detail-report_21.xsl
  • jmeter-results-report.xsl
  • jmeter-results-report_21.xsl

1. Open the Jtl file in wordpad or any other text editor and inser the following line:
<?xml-stylesheet type=”text/xsl” href=”<Path of Jmeter home>\extras\jmeter-results-report_21.xsl”?>
eg: <?xml-stylesheet type=”text/xsl” href=”D:\jakarta-jmeter-2.9\extras\jmeter-results-report_21.xsl”?>

This line should be inserted between the line <?xml version=”1.0″ encoding=”UTF-8″?> and <testResults version=”1.2″> as  shown below:

JTL file

2. Save the jtl file and open an excel worksheet.Drag the Jtl file into it. You are there.


XSL example

You see that *.jtl file is parsed and converted to Excel worksheet.

But wait a minute. You shoud save your result in xml format and not csv. To do so either change the default settings in JMeter properties files or in the configure option in Listeners as shown below:


Result Configure


IP Switching and Load Testing

IP Switching in Load testing

The most common use for IP Switching is when load testing against a load balancer. Load balancer typically use the IP address to route requests to a particular Web server in the farm.
So if you have 2 agents driving load to 3 Web servers, since all traffic is coming from two IPs (one on each agent), only two of the web servers would get all the traffic.
IP Switching provides a way to have traffic come from multiple IPs on the same agent, enabling the load balancer to balance load across the farm.
IP Switching will only work if you are running the test from the Controller/Agnet(remote execution).
To confirm current execution settings in VS2010:

    1. Under Test – Edit Test Settings – open the test settings that you wish to use. Check the Roles, and under Test Execution Method, make sure you have that set to Remote Execution then the Controller edit box should appear for you to type in the macine name. You can also save this as a new test settings.
    1. Under Test – Select Active Test Settings – make sure you set the test settings active for the one you edited above.
    1. In the Menu Test-Manage Test Controller all the agent machine should be listed
  1. When you submit your LoadTest, make sure that you see in the menu Test-Manage Test Controller that it shows all agent machine and the status switches to “Running Test”.

For more details refer the Visual Studio Performance testing quick reference guide.

Load Testing using The Grinder


The Grinder is an open source load testing tool. The Grinder uses Jython scripts and the scripts are executed using agents which can be distributed over the network. Property file is used to define tests and load.

The Grinder framework comprises three types of process or programs;

    1. Worker Process: Interpret Jython test scripts and perform tests using a number of worker threads


    1. Agent Process: Manage worker processes


    1. The Console:
        1. Coordinate the other processes
        1. Collate and display statistics
        1. Script editing and distribution




We will create a couple of batch files to conveniently start up the agents and console.

    1. Extract the zip file and copy at any location. E.g. C:\grinder
    1. First batch file “setgrinderenv.bat” will have following commands.

set GRINDERPATH=”C:\grinder”

set GRINDERPROPERTIES=”C:\grinder\grinder.properties”


    1. Second batch file “startconsole.bat”

call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.Console

    1. Third batch file “startagent.bat”

call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.Grinder %GRINDERPROPERTIES%

How to update Property file?

The load test is defined using the property file. The configuration entry grinder.script = http.py indicates the path of the Jython script which will be run. Other interesting configurations include the number of processes created by each agent (grinder.processes) and the number of threads for each process (grinder.threads).

I would also recommend to explicitly specify the log and the temporary directories:

# The directory in which worker process logs should be created.

grinder.logDirectory = log

 # Additional arguments to worker process JVMs.

grinder.jvm.arguments = -Dpython.cachedir=”C:\\ grinder\\tmp”

The Test

The load test can be written manually or can be generated through the TCP proxy provided with The Grinder.

Starting the TCP proxy to generate the load case could be done through yet another batch file:


call “C:\grinder\setGrinderEnv.cmd”

java -cp %CLASSPATH% net.grinder.TCPProxy -console -http > proxy-output.py

When TCP Proxy is started, display the following information:

Initializing as an HTTP/HTTPS proxy with the parameters:

Request filters:  EchoFilter

Response filters: EchoFilter

Local address:    localhost:8001

Engine initialised, listening on port 8001

This indicates that the TCPProxy is listening as an HTTP proxy on port 8001 (the default, but you can change it with -localPort).

Preparing the Browser

In the browser options dialog, set the proxy host to be the host on which the TCPProxy is running and proxy port to be 8001).    Run through your test scenario on your website. Having finished your run through, press “Stop” on the TCPProxy console and the generated script will be written togrinder.py.

The grinder.py file contains headers, requests and a logical grouping of requests into pages, of the recorded tests.

Once you’ve recorded your script you have two methods that you can use to replay your script:

    1. You can create a simple grinder.properties file and you can replay the recorded scenario with The Grinder. Your properties file should at least set grinder.script to grinder.py.
    1. Alternately you can use the console to distribute your script to an agent and set it as the script to run. Each agent will still need a simple grinder.properties file containing the console address, though you will not need to set the grinder.script property.

Will be continued….


Jmeter limitations with Monitoring server on load and how to overcome?

JMeter has option to add monitor test plan to monitor application servers. But it only works with Tomcat 5 status servlet. But any servlet container that supports JMX (Java Management Extension) can port the status servlet to provide the same information.

Also if user want want to use the monitor with other servlet or EJB containers, Tomcat’s status servlet will work with other containers for the memory statistics without any modifications. To get thread information, MBeanServer will require change in lookup to retrieve the correct MBeans.

But still it is not possible of Windows server IIS.

One of the way to overcome this situation is using Nagios. This can also be used in conjuction with JMeter. That is load is generated using JMeter and Nagios is used to monitor application server performance on load.

Now, the question is what is nagios? How it works ….

Nagios is System and network monitoring tool. It watches hosts and services that is specified and alerts when things go bad crosses threshold value ( this threshold value can be configured) and when they get better.

It works on Linux and linux like system.. BUT it can also MONITOR WINDOWS SERVER. This is the most important aspect of it.

The only requirement of running Nagios is Linux machine or its variant and c compiler.

On the next article I will explain the details of how it can be used to configure and monitor windows machine.