JMeter Quick Reference Guide

[Type the document subtitle]

Contents
Introduction .................................................................................................................................................. 3
JMeter Script structure ................................................................................................................................. 3
Test Plan .................................................................................................................................................... 4
Thread Group ............................................................................................................................................ 4
Samplers.................................................................................................................................................... 4
Config Elements ........................................................................................................................................ 4
Controllers................................................................................................................................................. 4
Assertions.................................................................................................................................................. 4
Post Processors ......................................................................................................................................... 4
Timers ....................................................................................................................................................... 5
Listeners .................................................................................................................................................... 5
Script Recording ............................................................................................................................................ 5
Script customizations .................................................................................................................................. 11
1. Parameterization ............................................................................................................................ 11
2. Correlation ...................................................................................................................................... 11
3. Page Verification ............................................................................................................................. 12
4. Transactions .................................................................................................................................... 12
5. Think times ...................................................................................................................................... 12
Samplers...................................................................................................................................................... 12
HTTP Request .......................................................................................................................................... 12
BSF Sampler ............................................................................................................................................ 14
Debug Sampler ........................................................................................................................................ 16
Config Elements .......................................................................................................................................... 17
Http Header Manager ............................................................................................................................. 17
HTTP Cookie Manager............................................................................................................................. 18
HTTP Cache Manager .............................................................................................................................. 20
HTTP Authorization Manager ................................................................................................................. 20
User Defined Variables ........................................................................................................................... 22
CSV Dataset Config.................................................................................................................................. 22
Logical Controllers....................................................................................................................................... 26
Transaction Controller ............................................................................................................................ 26
 If Controller ............................................................................................................................................. 26
While Controller ...................................................................................................................................... 27
Timers ......................................................................................................................................................... 28
Constant Timer........................................................................................................................................ 28
Constant Throughput Timer.................................................................................................................... 29
Gaussian Random Timer ......................................................................................................................... 30
Pre Processors ............................................................................................................................................. 30
User Parameters ..................................................................................................................................... 30
Post Processors ........................................................................................................................................... 31
Regular Expression Extractor .................................................................................................................. 31
Assertions.................................................................................................................................................... 34
Response Assertion ................................................................................................................................. 34
Listeners ...................................................................................................................................................... 34
View Results in Tree ................................................................................................................................ 34
Aggregate Report .................................................................................................................................... 37
View Results summary ............................................................................................................................ 38
Summary Report ..................................................................................................................................... 38
Running Performance Test ......................................................................................................................... 40
Load Generator configuration ................................................................................................................ 40
Conclusion ................................................................................................................................................... 40
Introduction
JMeter is an open source performance testing tool developed by Apache. The latest version of JMeter
can be downloaded from the URL: http://jmeter.apache.org/download_jmeter.cgi. Automation of the
user activities in JMeter is UI driven and hence no scripting language / Framework / IDE are needed to
start with. However, Individuals with Java development knowledge will have an added advantage of
extending the standard JMeter. This document is helpful in recording a JMeter script for Web
Applications, understanding the existing JMeter scripts, execute the scripts and debug if needed. The
target audience for this document is the individuals with Development background / Automation
background who meet the below requirements

Requirements
 Knowledge of Performance Testing concepts
 Basic understanding of Web Applications, browser features, HTTP(S) communication
 Basic Idea on XML (to read the JMX script using an editor), Java Script

JMeter Script structure

Test Plan

Config Thread
Listeners
Elements Groups

Config
Controllers Listeners Samplers
Elements

Post Config
Assertions Timers Listeners
Processors elements
From the above diagram, it is clear that Listeners and Config elements can be configured at any level,
thus defining the scope for them. If the listeners are defined at the Sampler level, they work only for
that sampler. If they are defined at the thread group level, they can work with all the samplers under
the thread group. If they are defined at the Test Plan level, they are applicable to all the thread groups
and all the samplers under the thread groups.

However, this works a little different for the Config elements. Each of the config elements have their
own scope which would be explained in detail at the Config Elements section.

Test Plan
A test plan contains the overall settings of the performance test. A test plan can have multiple Config
elements, listeners and Thread Groups. The test plan can control the execution (parallel or sequential) of
thread groups and can also be used to save the responses.

Thread Group
A thread group is where the number of threads (users), ramp-up rate and the start times of the thread
group are defined. All the items under a thread group are executed by multiple threads/users. A thread
group can have multiple samplers, config elements, controllers etc.

Samplers
These are the actual requests made from the JMeter tool. These samplers can be a HTTP Request, Web
Service request or JDBC request or can be even a java request. For performance testing the web
applications using JMeter, each thread group will have several HTTP requests which will be executed by
multiple threads concurrently and thus causing the load on the web application

Config Elements
Config elements are the ones to needed / can be configured the way the samplers /thread groups / test
plan are executed. The most commonly used HTTP config elements are HTTP Cookie Manager, HTTP
Cache manager, HTTP Auth Manager. Similarly to run a JDBC sampler, the JDBC config element has to
be specified.

Controllers
Controllers are used to control the flow of a thread through the thread group. All the conditions like If,
for, while etc. are the examples of Controllers

Assertions
Assertions are to validate the response that is received when a request (a sampler is executed) is made
to the application. The assertions can be text assertions, XML assertions, Xpathetc

Post Processors
Post processors are used to perform actions once a response is received for a particular sampler
request. The most commonly used post processor is the regular expression extractor
Timers
Timers are used to delay the execution of the thread or to make the thread wait for the specified time.
The commonly used timers are constant timer, Gaussian random timer etc

Listeners
Listeners are the reporting entity of JMeter which can be configured at the sampler / thread group /test
plan level. The most commonly used listeners are View results tree, View results summary and
aggregate report.

Script Recording
Script recording in JMeter can be done by sniffing all the communication that is happening on a proxy.
Below are the steps involved in recording a sample web application.

1. Launch JMeter from the bin folder by clicking on JMeter.bat

2. Add a thread group to the test plan. Right click on Test plan  Add  threads  thread Group

3. Add Http(s) script recorder to workbench. Right click on Work Bench  Add  Non-Test
Elements  HTTP(S) Test Script Recorder

4. Configure HTTP(S) Test Script Recorder. Specify the proxy port (8080 is default). Choose Target
Controller as Test Plan > Thread Group and Grouping as “Put each group in a new transaction
controller”, click on Add suggested Excludes
5. Click on Start. Click OK on the pop-up. Now JMeter is configured to listen to all the
communication happening on port 8080.
6. Launch your browser and go to network settings and configure the browser to run on proxy. In
IE, the navigation is: Tools  Internet options  connections  LAN Settings  Use a proxy
server for your LAN. Below is the screenshot:
In case of Firefox, the navigation is Tools  Options  Advanced  Network  Settings 
Manual Proxy configuration. Screenshot is as below:
7. Launch the application in the browser which is running on the proxy. Under thread group a new
transaction controller should be created as seen below:

8. Click on Transaction controller and change the Name of the transaction to make more
meaningful.
9. Perform the next user action and rename the transaction controller name. If you see more than
one transaction controller being recorded for the same user action, move all the requests under
the transaction controller to one and rename the controller.
10. Repeat this for the complete navigation to be automated. Once the complete navigation is
recorded, go to HTTP(S) Test Script Recorder and click on Stop Button.
 11. Save the JMeter script. The script would be save as a JMX file and can be viewed in any editor as
an XML file. When loaded in JMeter, the script is seen as UI controls. Each element of the
JMeter script is explained in detail in the coming sections.
Note: Ensure to change the browser settings to normal.

Script customizations
Once a JMeter script is recorded, it cannot be played back or it cannot be used directly for the
performance test. Any Performance test script should be customized to implement the below to
simulate the realistic user behavior on the application:

1. Parameterization – To send different user inputs to the script. This is to simulate the real
user inputs like the user name and passwords, search criteria, billing and shipping address etc. In
JMeter, the most common way of implementing parameterization is through CSV data set
config, which is a part of Config Elements. CSV Data Set Config is used to read the values from a
CSV file and store the values into JMeter variables.
2. Correlation – Handling the dynamic data in the user request. This is to simulate the real user
behavior of user selections either check boxes, radio buttons or dropdown picks etc.
Correlations involve in identifying the dynamic data of a request and capture the dynamic data
from the any of the previous responses and pass on to the current request. Regular Expression
extractor which is a part of Post processors is used for correlation.
 3. Page Verification: This is to ensure that the correct response is received during the
performance tests. A text which is static, specific to that request would be searched. If the text
is not found, the tool assumes that the response received is not a valid response. Response
Assertion which is a part of Assertions is commonly used for Page verification with the Web
based applications
4. Transactions: The objective of this customization is to measure the response time for each
user action. An user action can contain more than one request and to measure the end user
experience all the such requests which belong to one user action are clubbed together in JMeter
as Transaction Controller, which provides the overall response time of the all the requests
5. Think times: To simulate the real user wait times between the requests (to enter the inputs
/ think / reading the content), think times should be included in the scripts. In JMeter, Timers
are used to wait between the user requests.

Samplers

HTTP Request
Http Request belongs to the Sampler category. The core of a Web based JMeter script is the HTTP
Requests. An Http request (HTTP Sampler) in JMeter looks as below:
The most important attributes in a HTTP request are:

Server Name or IP: Host name or URL of the application

Attribute Name Description Example(s)

Server Name or IP The URL of the Icint
application being 172.16.10.28
tested. This should Google.com
only include the Icsta.hps.com
name/IP address.
Should not contain
the protocol, port
etc
Port Number Port on which the 8080
application is 9001
 running. If the 9030
protocol is http, it 1080
runs on port 80 by
default and if the
protocol is https,
the default port is
443. Default ports
need not be
mentioned
Protocol The protocol the HTTP/HTTPS
application uses.
Method The HTTP Method The request can be sent to the server using HTTP
that is used to send request methods like GET, POST, PUT, DELETE
the request to the
server.
Path The relative path of /hcas/Authentication
the user request /search
Parameters/Body Data The form data that For parameters:
is sent to the Name: Username
server as part of Value: QaTestUser_00965
the request. If it is Name: Password
parameters, the Value: testP@55
data would be sent The same would be seen as below if it is body data:
as key and value Username=QaTestUser_00965&Password=testp@55
pairs. If it is body
data the looks like
a query string.
Encode The data in the For example of password field is checked for encode
parameter will be it would be seen as testP%4055 where %40 is the
URL encoded if this URL encoded form of the character “@”.
is checked
Use keep Alive enables to keep the connection open after serving the response. This is used to
simulate the persistent connections in HTTP1.1.

BSF Sampler
This sampler allows you to execute a piece of code written in any BSF scripting language. By default
JMeter supports the below languages in a BSF sampler:

 Java Script
 Jexl
 Xslt

Below is the screenshot of this sampler.

We would need to select the language type from the dropdown. In the above example, JavaScript has
been selected.

Attributes:

Below are the important attributes of a BSF sampler

Attribute Description Example

Name of the BSF scripting
language to be used. Not all
the languages in the drop- Java script
down list are supported by Jexl
Scripting Language default. The following are Xslt
supported: jexl, javascript, xslt. Python
Others may be available if the
appropriate jar is installed in
the JMeter lib directory.
Name of a file to be used as a
BSF script with the full path. if a
relative file path is used, then it
Script File C:\users\testacct\desktop\sample.js
will be relative to directory
referenced by "user.dir"
System property
 List of parameters to be passed
Parameters
to the script file or the script.
The script can be directly
written in this section if the file
name is not specified. If the file
Script name is specified, only that Refer to the screenshot
part would be executed and
the code written here would be
ignored.

Debug Sampler
The Debug sampler is used to debug the script, especially to ensure all the JMeter variables has got the
right data in them. This is added during the debug phase of the script and should be deleted / disabled
while executing the performance test. The Debug Sampler can be configured to control the list of things
to be displayed response data Pane in the View Results tree listener. Usually the JMeter Variables is the
only one set to true with the debug sampler.

Below are the attributes that are given to a Debug Sampler

Attributes:
Attribute Description Example
Descriptive name for this
Name element that is shown in the No
tree.
If this is set to yes, all the JMeter
properties would be displayed in
JMeter Properties True/False
the Response pane of View
results tree listener
To display the JMeter variables
JMeter Variables and their values in the response True/False
pane of view results tree listener
System Properties To display the system properties True/False
Config Elements

Http Header Manager

An important aspect of a HTTP Request is the headers. The headers in a JMeter script are recorded
as below:

Usually the header management is taken care by the performance tools automatically. However, if
the application has some customized headers, those have to be handled in the request explicitly.

HTTP Header Manager is always added as a child to HTTP Request sampler. The scope of Http
Header Manager is usually at the sampler level because each request can have different request
headers. If most of the request headers are the same for all the Http requests, this can be defined at
the thread group level so that it is applied for all the Http request samplers. The additional headers
can be added through another Http Header manager at the sampler level. For example the below
screenshot highlights the way additional headers are added.

The default headers are added at the thread group level and the additional headers are added at the
sampler level.
 When the request is executed, the View results tree listener’s Request pane shows that all the seven
(7) headers are sent as part of the request. Please find below the screenshot:

HTTP Cookie Manager

The Cookie Manager element has two functions:

1. Store and send the cookies similar to that of a web browser - If you have an HTTP Request and
the response contains a cookie, the Cookie Manager automatically stores that cookie and will
use it for all future requests to that particular web site. Each JMeter thread has its own "cookie
storage area". So, if you are testing a web site that uses a cookie for storing session information,
each JMeter thread will have its own session. Note that such cookies do not appear on the
Cookie Manager display, but they can be seen using the View Results Tree Listener.
2. Manually add a cookie to the Cookie Manager - However, if you do this, the cookie will be
shared by all JMeter threads.

Usually Http Cookie Manager is added at the thread group level.

Attributes:

Attribute Description Required

Name Descriptive name for this element that is shown in the tree. No
Clear Cookies If selected, all server-defined cookies are cleared each time the main
Yes
each Iteration Thread Group loop is executed.
The cookie policy that will be used to manage the cookies.
Cookie Policy Yes
"Compatibility" is the default, and should work in most cases.
HC3CookieHandler (HttpClient 3.1 API) or HC4CookieHandler
Implementation (HttpClient 4 API). Default is HC3CookieHandler. Yes

This section is used to add cookies manually. However these cookies

User-Defined
are usually hard coded values. You can add / delete cookies, save No
Cookies
them to a file and can be loaded later
Add Button Add an entry to the cookie table. N/A
Delete Button Delete the currently selected table entry. N/A
Load a previously saved cookie table and add the entries to the
Load Button N/A
existing cookie table entries.
Save the current cookie table to a file (does not save any cookies
Save As Button N/A
extracted from HTTP Responses).
HTTP Cache Manager
The HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope. By
default, Cache Manager will store up to 5000 items in cache using LRU algorithm. Use property to
modify this value.

The scope of the Http Cache Manager is usually at the thread group level.

HTTP Authorization Manager

The Authorization Manager used to send the login information for web pages that are restricted using
server authentication. The most commonly used method is windows NTLM authentication mechanism.
This type of authentication is seen when the browsers access a restricted page, a login dialog box is
displayed. JMeter transmits the login information when it encounters this type of page. The scope of a
Http Authorization manager is at the thread group level or at the test plan level.
Attributes

Attribute Description Required

Name Descriptive name for this element that is shown in the tree. No
Clear auth on Used by Kerberos authentication. If checked, authentication will be done Yes
each on every iteration of Main Thread Group loop even if it has already been
iteration? done in a previous one. This is helpful to simulate a new virtual user every
iteration. The limitation is that, this does not work in case of Basic, Digest
authentication types. The NTLM authentication uses the same auth info for
all iterations.
Base URL A partial or complete URL that matches one or more HTTP Request URLs. Yes
As an example, say you specify a Base URL of "https://svsta/" with a
username of "user" and a password of "pass". If you send an HTTPS request
to the URL "https://svsta/ ", the Authorization Manager sends the login
information for the user named, "user".
Username The username to authorize. Yes
Password The password for the user. Yes
Domain The domain to use for NTLM. No
Realm The realm to use for NTLM. No
Mechanism Type of authentication to perform. JMeter can perform different types of
authentications based on used Http Request Sampler Implementations:
Java implemented sample can perform only Basic Authentication, whereas
http client 3.1 can perform Basic and digest type of authentication and
HttpClient 4 can perform Basic, Digest and Kerberos types of
Authentications
User Defined Variables
User Defined Variables are like Global Variables which will be processed at the beginning of the test plan
execution irrespective of their position in the test plan at the beginning / inside a thread group or inside
a sampler. Hence the scope of the user defined variables is at the test plan level and the value of a
Global variable cannot be another variable which is defined at a later stage of the test plan. Below are
the attributes for User Defined Variables element.

Attributes

Attribute Description Required

Descriptive name for this
Name element that is shown in the No
tree.
User Defined Variables Variable name/value pairs. No

CSV Dataset Config

The most common way of achieving parameterization is reading the values from a file. In JMeter, this is
achieved through CSV Data Set Config which is used to read lines from a file, and split them into
variables. If a CSV dataset config is specified within a thread group, then the scope is within the thread
group. Threads from other thread group cannot access the file. If the same is defined at the test plan
level, then all the threads under any thread group can share the contents of the CSV/text file mentioned
in the CSV dataset config. The most important aspect of a CSV Dataset config is the sharing mode of the
file among the threads.
Attributes

Attribute Description Required

Descriptive name for this element that is shown in
Name No
the tree.
Name of the file to be read.
Filename Yes
The encoding to be used to read the file, if not the
File Encoding No
platform default.
Variable Names List of variable names (comma-delimited). Yes
Delimiter to be used to split the rows read from the
Delimiter Yes
file
Should the CSV file allow values to be quoted? If
Allow quoted data? enabled, then values can be enclosed in " - double- Yes
quote
Should the file be re-read from the beginning on
Recycle on EOF? Yes
reaching EOF? (default is true)
Should the thread be stopped on EOF, if Recycle is
Stop thread on EOF? Yes
false? (default is false)

Sharing Mode:
Sharing Mode Number file instances created
All Threads One instance for the entire test plan and every
thread reads a line from the file and is updated
every round. The file scope is global. All the thread
groups and threads read from the same file.
Current thread group One instance created per thread group. If there
are 2 thread groups 2 instances of the file is
created one for each thread and the thread group
reads the values from their own instance and is
updated every round. The scope is local to thread
group. Each thread group will have its own
instance and all the threads under the thread
group will read a line from the file.
Current thread One instance per thread is created. If there are
total of 10 threads, then 10 instances of the file
are created. The scope is local to each thread and
reads a value from the file every round.

Below is the pictorial representation of how the file is being read with various sharing mode options:

All threads sharing mode

Current thread group sharing mode

Current Thread sharing mode

Logical Controllers
As the name suggests, the logical controllers are used to control the execution of a JMeter script. The
most commonly used controllers are listed below:

Transaction Controller

The transaction controller is used to group all the samplers that make a transaction. This is used to
measure the overall response time of a transaction instead of an individual sampler. When transaction
controller is added, in the summary report or Aggregate report, the transaction controller would also be
seen and its response times are measured.

Example: When the user enters the user name and password in a web application, internally the
application may have 5 – 6 requests. However, from the end user point of view it is just logging into the
application. In this case, the overall response time for these 5 – 6 requests would make more sense to
the end users than the individual request’s response time. Hence, all these 5 – 6 requests are grouped
using a transaction controller.

Attributes

Attribute Description Required

Descriptive name for this controller that is shown in
Name Yes
the tree, and used to name the transaction.
If this is checked, only the transaction’s response
time is displayed in the aggregate report or summary
Generate Parent Sample Yes
report. If this is not checked, the individual requests
and transaction are logged for their response times.
If this is checked, the time taken at the Timer and
Include duration of timer and
pre-processor and post processors requests would
pre-post processors in Yes
also be included in the transaction’s response time.
generated sample
Recommended is not to check this attribute.

If Controller
This is similar to any other If condition in any other language. If some requests are to be made based on
condition, this controller is used. The condition is usually evaluated as a java script code and based on
the condition the child samplers would be executed.

Attributes

Attribute Description Required

Name
Condition (default
Javascript)
Interpret Condition as
Variable Expression?
Evaluate for all children
Descriptive name for this controller that is shown in the
No
tree.
By default the condition is interpreted as Javascript code
that returns "true" or "false", but this can be overridden
(see below). Also note that, if the JMeter variables used
here are the regular expression extractors, it is always
recommended to evaluate them as strings. For example Yes
Count is an regular expression extractor and there has to
be a condition to check if the value is equal to zero or not,
the recommended condition is:
“${count}”==”0” instead of ${count}==0
If this is selected, then the condition must be an
expression that evaluates to "true" (case is ignored). For
example, ${FOUND} or ${__jexl(${VAR} > 100)} . Unlike Yes
the Javascript case, the condition is only checked to see if
it matches "true" (case is ignored).
If this is checked, then the If condition is executed for
every child of the controller. Else, it would be checked Yes
only once.

While Controller
The While Controller runs its children until the condition is "false".
Attributes:

Attribute Description Required

Descriptive name for this controller that is shown in the
Name Yes
tree, and used to name the transaction.
Condition blank, LAST, or variable/function Yes

Timers
Constant Timer
A constant Timer will introduce a fixed delay between consecutive requests of the same thread. . This is
used as Think Times between two transaction controllers to emulate real time traffic.

Parameters

Attribute Description Required

Descriptive name for this timer
Name No
that is shown in the tree.
Number of milliseconds to
Thread Delay Yes
pause.
Constant Throughput Timer
Constant Throughput Timer will introduce random delays between requests in such a way that a
load/stress of required throughput is sent to the application.

Attributes

Attribute Description Required

Descriptive name for this timer that is shown in the
Name No
tree.
Target Throughput Throughput we want the timer to try to generate. Yes
 This thread only - each thread will try to
maintain the target throughput. The overall
throughput will be proportional to the
number of active threads.
 All active threads in current thread group - the
target throughput is divided amongst all the
active threads in the group. Each thread will
delay as needed, based on when it last ran.
 All active threads - the target throughput is
divided amongst all the active threads in all
Thread Groups. Each thread will delay as
Calculate Throughput
needed, based on when it last ran. In this Yes
based on
case, each other Thread Group will need a
Constant Throughput timer with the same
settings.
 All active threads in current thread group
(shared) - as above, but each thread is delayed
based on when any thread in the group last
ran.
 All active threads (shared) - as above; each
thread is delayed based on when any thread
last ran.
Gaussian Random Timer
A Uniform Random Timer will delay consecutive requests of the same thread by a random interval
within lower and upper bounds. The random interval follows a Gaussian curve distribution. In the
example below the thread waits between 300ms to 400ms, with a variation to the value which follows a
Gaussian curve.

Attribute Description Required

Descriptive name for this timer that is shown in the
Name No
tree
Deviation Deviation in milliseconds. Yes
Number of milliseconds to pause in addition to the
Constant Delay Offset Yes
random delay.

Pre Processors
User Parameters
User parameters work exactly the same way as user defined variables, except that they are executed
only at their designated position. All the user defined variables are executed at the beginning of the test
plan and hence no JMeter variables that are captured or created during the execution cannot be used in
User defined variables. User Parameters are helpful to serve this purpose. The JMeter variables created
or captured before user parameters can be used in the user parameters. Below is the screenshot of a
simple user parameter:

Below are the attributes of user parameters:

Attribute Description Required
Update Once per Iteration If this is not set, the variable is NO
evaluated every time it has to be
used. If this is set the variable is
evaluated once per Iteration per
user. The most common thing is
to check this field.
Name Name of the variable YES
User_1 Value of the variable YES

There is a provision to send different values to different threads instead of the same value. This can be
achieved by clicking on Add User and corresponding value as seen below:

Now in the above example, thread 1 will read the value Test1, thread 2 will read the value Test2, thread
3 will read Test 3, and thread 4 will read the value 4. If there are more threads, then thread5 will read
the value Test1, thread 6 will read Test2 and so on.

There is also provision to add multiple variables by click on Add Variable button.

Post Processors

Regular Expression Extractor

Regular expression extractor is used to capture the dynamic data from the response (header or body /
from the main sample or sub samples or even from another JMeter variable) and store it into a variable
for future use. It allows the user to extract values from a server response using a Perl-type regular
expression. As a post-processor, this element will execute after each Sample request in its scope,
applying the regular expression, extracting the requested values, generate the template string, and store
the result into the given variable name.
Attributes:

Attribute Description Required

Name Descriptive name for this element that is shown in the tree. No
Reference Name The name of the JMeter variable in which to store the result. Yes
The regular expression used to parse the response data. This
Regular Expression must contain at least one set of parentheses "()" to capture a Yes
portion of the string.
The template used to create a string from the matches found.
This is an arbitrary string with special elements to refer to
Template groups within the regular expression. The syntax to refer to a Yes
group is: '$1$' to refer to group 1, '$2$' to refer to group 2,
etc. $0$ refers to whatever the entire expression matches.
Indicates which match to use. The regular expression may
match multiple times.

Match No.  Use a value of zero to indicate JMeter should choose a Yes
random match.
 A positive number N means to select the nth match.

If the regular expression does not match, then the reference No, but
Default Value
variable will be set to the default value. recommended
Examples:

Assuming the server response is as below:

Regular expression Extractor and their outputs would be as below:

Regular Expression Template Match No Output

2014-05-
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $1$ 1 22T00:00:00
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $2$ 1 23
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $3$ 1 700.10000000
2014-05-
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $1$ 2 23T00:00:00
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $2$ 2 52
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $3$ 2 2083.68000000
2014-05-
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $1$ 0 28T00:00:00
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $2$ 0 36
"closeDate":"(.*?)","txnCount":(.*?),"netAmount":(.*?)}, $3$ 0 826.18000000
Assertions

Response Assertion
Response Assertions are used to validate if the response received is valid or not. This can be done
either by searching for the response code or searching for some static text which is specific to that
request. The most commonly used response assertion is as below:

Listeners
Listeners are the reporting entities in JMeter that gather some details from the test. Each listener serves
a purpose and below is the most important listeners that are used with any JMeter tests:

View Results in Tree

This listener is widely used while debugging the script for single user / multi users. This listener shows
all the samplers in a tree view and every sampler has three important panes as shown below:
The pane Sampler request shows the response headers, time taken to load the response and high level
details of the response. If any of the samplers is failed, it would be marked in Red in the tree view.
The request pane shows the request headers and body (if any) to check if the request is sent properly to
the server or not:

Response Data is the response received from the server

Aggregate Report
This gives the overall details about the samplers like the sampler name, the total number of times a
sampler executed, response times (average, median, 90% line, min, max), error rate, throughput rate
and response size

The aggregate report can be written to a file so that the data can be used later.

The contents of an Aggregate Report are as below:

 Label – The Sampler Name / Transaction controller name

 # Samples: Number of times a sampler or transaction executed
 Average/ Median / Min / Max: The corresponding response time metrics in milliseconds for the
specific sampler
 90% line: The maximum response time for 90% of samples. This is calculated as the 90th value
when the response times are sorted for a sampler which was executed 100 times.
 Error%: The % of the time the sampler / transaction controller failed
 Throughput: The total number of times the sampler executed per unit time (seconds or minutes)
 KB/S: The total response size received for the sampler per unit time

The same data can be exported to a CSV file which can be used later. Configure button enables to
control what has to be written to the file.
View Results summary
View Results summary stores the information about every sampler, which will be helpful in analyzing a
sampler’s trend. Again this data can be written to a file for future use.

Summary Report
The additional information that summary report provides the std. deviation of the response times from
their average values.

Other listeners
All the listeners that start with jp@gc are the graphical representation of the corresponding data. To
have them listed under the listeners, all the standard plugins should be imported. They can be imported
from the URL: http://jmeter-plugins.org/
Running Performance Test
Thread pool has to be configured to specify the user load, duration of the test. Once this information is
verified, click on Run button to start the test. This will be running the test with the specified users for
specified duration. However, to ensure that the script is running without errors, please check the log by
clicking on the Warning Icon to the top right. Monitor the machine’s CPU and memory utilization during
the test to figure out the maximum user load that can be generated from a single machine.

Load Generator configuration

JMeter supports the distributed testing where the user load can be distribute across several machines
called load generators. The Load Generators should be able to communicate with the controller
machine (by default JMeter listens on port 1099). Running the distributed tests involve in steps

1. Configure jmeter.properties file to add the host name or IP address of the Load Generators:

2. Start jmeter-server.bat in all the load generators

Once the above steps are completed, close JMeter and open again (to take the properties change
reflected) and navigate to Run  Remote start choose one of the LG and click. This will launch the
test from the chosen load generator. The most important point to be remembered is the thread
pool settings are transferred to the LG and each LG will generate the same number of threads. For
example if a thread pool has 25 threads and distributed testing is in place, the final user load would
be 25* number of LGs configured.

Conclusion
This document is to provide a basic understanding of JMeter for Web Application automation.
Considering the features provided by JMeter, this document may not be useful for other protocols
like Web services, JDBC etc. To automate such protocols, the individuals should have at least the
basic idea on how the corresponding protocols work. The detailed documentation would be
available at the URL: http://jmeter.apache.org/usermanual/index.html