Apache Jmeter Best Practices and Performance Tuning Tips

1. Run Tests in Non-GUI Mode: Running JMeter using command line in non-GUI mode is very
simple. Keep .JMX file in jmeter bin folder.
A. Open command prompt
B. Go into JMeter’s bin folder
C. Enter following command, jmeter -n –t test.jmx -l testresults.jtl
(use jmeter -n -t test.jmx test.jtl, add a '-l' argument before the test plan name for
listeners.)
View test result: After completing the test, a JTL file will be generated at jmeter/bin folder
A. Open JMeter in GUI mode.
B. Add any listener Eg. View Results Tree.
C. Click Browse button of the file name field in listener.
D. Open testresult.jtl file. (You should be able to see the result in listener now.)
2. Increase the maximum heap size to ~80% of your total available physical RAM.
3. Use Remote and Distributed testing for larger load testing
4. Do not load more than 300 threads per Jmeter engine
5. Do not add Listeners to your Jmeter test plan (Disable ALL Listeners During the Test Run)
6. Do not add Graphs to your Jmeter test plan
7. Monitor the command prompt of Jmeter during testing (non-GUI mode) Monitor the log during
testing (GUI mode)
8. Erase the local path of all the CSV Data Set config files
9. Use naming conventions for all the elements
10. Use JTL file name (XML format) to store the logs
11. Add following properties for better output in jmeter.properties file.
jmeter.save.saveservice.output_format=csv jmeter.save.saveservice.data_type=false
jmeter.save.saveservice.label=true jmeter.save.saveservice.response_code=true
jmeter.save.saveservice.response_data.on_error=false
jmeter.save.saveservice.response_message=false jmeter.save.saveservice.successful=true
jmeter.save.saveservice.thread_name=true jmeter.save.saveservice.time=true
jmeter.save.saveservice.subresults=false jmeter.save.saveservice.assertions=false
jmeter.save.saveservice.latency=true jmeter.save.saveservice.bytes=true
jmeter.save.saveservice.hostname=true jmeter.save.saveservice.thread_counts=true
jmeter.save.saveservice.sample_count=true
jmeter.save.saveservice.assertion_results_failure_message=false
jmeter.save.saveservice.timestamp_format=HH:mm:ss
jmeter.save.saveservice.default_delimiter=; jmeter.save.saveservice.print_field_names=true
12. relevant Assertions and Post-processors elements only
13. Do not use XPATH extractor
14. SR 223 and Groovy for scripting
15. Generate reports after run
16. Use Up-to-Date Software :

pg. 1
 17. Your test might fail if your software is out of date. Make sure you’re using the most recent
versions of the following:
Java: use the latest 64-bit version of Java SE JDK or Server JRE where possible
JMeter: it’s always best to use the latest version of JMeter as the new releases contain performance improvements and bug fixes in
addition to any new features.

Still Not Working?

Employ distributed testing by adding more hosts and configuring them manually. JMeter supports the
distributed mode when one master machine orchestrates several slaves, meaning the load comes from several
generators. Remember that the master machine doesn’t generate any load, so you’ll need three hosts to
increase throughput by a factor of two.

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 has 3 parts:
a. JMeter Master,
b. JMeter Slaves and
c. Target.

Client

Server

pg. 2
Distributed setup prerequisite
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 (Server)

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

 On the slave systems, go to jmeter/bin directory and execute file "jmeter-
server.bat".
 Assume that a slave machine has IP address: 192.168.0.206. On
windows, you should see a window appear like following figure:

Master Configuration (Client)

 Open jmeter.properties and edit the line “remote_hosts=127.0.0.1”.

 Add IP address of the slave machines e.g.:
“remote_hosts=192.168.1.5,192.168.1.6,192.168.8”

 On the master systems, go to /bin directory and edit

file jmeter.properites, add IP slave machine as below

pg. 3
 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 Test_07_06.jmx -l Test_07_06_result.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)

Note: If you want load 1000 users on 5 systems (server / slave), then run for 200
users on Master or Client.

Troubleshooting
If you are unable to run test form the above machine and see below error, simply ask
owner of slave machine to run the jmeter-server.bat File.

pg. 4
Limitation:

There are some basic limitations for distributed testing. Here's list of the known
items:

 Server and all clients must be on the same subnet.

 Distributed testing required target server to have large processing power. The
target Server could be easily overloaded in case it gets too many requests by
distributed JMeter tests.
 A single JMeter can only handle a limited number of threads (100- 300 threads).

pg. 5