Lỗi appropriate loader to handle this file type

Samplers perform the actual work of JMeter. Each sampler [except ] generates one or more sample results. The sample results have various attributes [success/fail, elapsed time, data size etc.] and can be viewed in the various listeners.

FTP Request

This controller lets you send an FTP "retrieve file" or "upload file" request to an FTP server. If you are going to send multiple requests to the same FTP server, consider using a Configuration Element so you do not have to enter the same information for each FTP Request Generative Controller. When downloading a file, it can be stored on disk [Local File] or in the Response Data, or both.

Latency is set to the time it takes to login.

Screenshot of Control-Panel of FTP Request

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Server Name or IP

Domain name or IP address of the FTP server.

Yes

Port

Port to use. If this is \>0, then this specific port is used, otherwise JMeter uses the default FTP port.

Remote File:

File to retrieve or name of destination file to upload.

Yes

Local File:

File to upload, or destination for downloads [defaults to remote file name].

Yes, if uploading [*]

Local File Contents:

Provides the contents for the upload, overrides the Local File property.

Yes, if uploading [*]

get[RETR] / put[STOR]

Whether to retrieve or upload a file.

Yes

Use Binary mode?

Check this to use Binary mode [default ASCII]

Yes

Save File in Response?

Whether to store contents of retrieved file in response data. If the mode is ASCII, then the contents will be visible in the .

Yes, if downloading

Username

FTP account username.

Usually

Password

FTP account password. N.B. This will be visible in the test plan.

Usually

HTTP Request

This sampler lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP requests to retrieve them. The following types of embedded resource are retrieved:

images
applets
stylesheets [CSS] and resources referenced from those files
external scripts
frames, iframes
background images [body, table, TD, TR]
background sound

The default parser is org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser. This can be changed by using the property "htmlparser.className" - see jmeter.properties for details.

If you are going to send multiple requests to the same web server, consider using an Configuration Element so you do not have to enter the same information for each HTTP Request.

Or, instead of manually adding HTTP Requests, you may want to use JMeter's to create them. This can save you time if you have a lot of HTTP requests or requests with many parameters.

There are three different test elements used to define the samplers:

AJP/1.3 Sampler uses the Tomcat mod_jk protocol [allows testing of Tomcat in AJP mode without needing Apache httpd] The AJP Sampler does not support multiple file upload; only the first file will be used. HTTP Request this has an implementation drop-down box, which selects the HTTP protocol implementation to be used:Javauses the HTTP implementation provided by the JVM. This has some limitations in comparison with the HttpClient implementations - see below.HTTPClient4uses Apache HttpComponents HttpClient 4.x. Blank Value does not set implementation on HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.propertiesGraphQL HTTP Request this is a GUI variation of the HTTP Request to provide more convenient UI elements to view or edit GraphQL Query, Variables and Operation Name, while converting them into HTTP Arguments automatically under the hood using the same sampler. This hides or customizes the following UI elements as they are less convenient for or irrelevant to GraphQL over HTTP/HTTPS requests:

Method: Only POST and GET methods are available conforming the GraphQL over HTTP specification. POST method is selected by default.
Parameters and Post Body tabs: you may view or edit parameter content through Query, Variables and Operation Name UI elements instead.
File Upload tab: irrelevant to GraphQL queries.
Embedded Resources from HTML Files section in the Advanced tab: irrelevant in GraphQL JSON responses.

The Java HTTP implementation has some limitations:

There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread.
The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections.
No support of Kerberos authentication
It does not support client based certificate testing with Keystore Config.
Better control of Retry mechanism
It does not support virtual hosts.
It supports only the following methods: GET, POST, HEAD, OPTIONS, PUT, DELETE and TRACE
Better control on DNS Caching with

Note: the FILE protocol is intended for testing purposes only. It is handled by the same code regardless of which HTTP Sampler is used.

If the request requires server or proxy login authorization [i.e. where a browser would create a pop-up dialog box], you will also have to add an Configuration Element. For normal logins [i.e. where the user enters login information in a form], you will need to work out what the form submit button does, and create an HTTP request with the appropriate method [usually POST] and the appropriate parameters from the form definition. If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.

A separate SSL context is used for each thread. If you want to use a single SSL context [not the standard behaviour of browsers], set the JMeter property:

https.sessioncontext.shared=true

By default, since version 5.0, the SSL context is retained during a Thread Group iteration and reset for each test iteration. If in your test plan the same user iterates multiple times, then you should set this to false.

httpclient.reset_state_on_thread_group_iteration=true

Note: this does not apply to the Java HTTP implementation.

JMeter defaults to the SSL protocol level TLS. If the server needs a different level, e.g. SSLv3, change the JMeter property, for example:

https.default.protocol=SSLv3

JMeter also allows one to enable additional protocols, by changing the property https.socket.protocols.

If the request uses cookies, then you will also need an . You can add either of these elements to the Thread Group or the HTTP Request. If you have more than one HTTP Request that needs authorizations or cookies, then add the elements to the Thread Group. That way, all HTTP Request controllers will share the same Authorization Manager and Cookie Manager elements.

If the request uses a technique called "URL Rewriting" to maintain sessions, then see section for additional configuration steps.

Screenshot of Control-Panel of HTTP Request

HTTP Request Advanced config fields

Screenshot of Control-Panel of GraphQL HTTP Request

Variables field for GraphQL HTTP Request

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Server

Domain name or IP address of the web server, e.g. www.example.com. [Do not include the // prefix.] Note: If the "Host" header is defined in a Header Manager, then this will be used as the virtual host name.

Server is required, unless:

it is provided by
or a full URL including scheme, host and port [scheme://host:port] is set in Path field

Port

Port the web server is listening to. Default: 80

Connect Timeout

Connection Timeout. Number of milliseconds to wait for a connection to open.

Response Timeout

Response Timeout. Number of milliseconds to wait for a response. Note that this applies to each wait for a response. If the server response is sent in several chunks, the overall elapsed time may be longer than the timeout.

A can be used to detect responses that take too long to complete.

Server [proxy]

Hostname or IP address of a proxy server to perform request. [Do not include the // prefix.]

Port

Port the proxy server is listening to.

No, unless proxy hostname is specified

Username

[Optional] username for proxy server.

Password

[Optional] password for proxy server. [N.B. this is stored unencrypted in the test plan]

Implementation

Java, HttpClient4. If not specified [and not defined by HTTP Request Defaults], the default depends on the value of the JMeter propertyjmeter.httpsampler, failing that, the HttpClient4 implementation is used.

Protocol

HTTP, HTTPS or FILE. Default: HTTP

Method

GET, POST, HEAD, TRACE,OPTIONS, PUT, DELETE, PATCH [not supported forJAVA implementation]. With HttpClient4, the following methods related to WebDav are also allowed: COPY, LOCK, MKCOL, MOVE,PROPFIND, PROPPATCH, UNLOCK, REPORT, MKCALENDAR,SEARCH.

More methods can be pre-defined for the HttpClient4 by using the JMeter propertyhttpsampler.user_defined_methods.

Yes

Content Encoding

Content encoding to be used [for POST, PUT, PATCH and FILE]. This is the character encoding to be used, and is not related to the Content-Encoding HTTP header.

Redirect Automatically

Sets the underlying http protocol handler to automatically follow redirects, so they are not seen by JMeter, and thus will not appear as samples. Should only be used for GET and HEAD requests. The HttpClient sampler will reject attempts to use it for POST or PUT.

Warning: see below for information on cookie and header handling.

Follow Redirects

This only has any effect if "Redirect Automatically" is not enabled. If set, the JMeter sampler will check if the response is a redirect and follow it if so. The initial redirect and further responses will appear as additional samples. The URL and data fields of the parent sample will be taken from the final [non-redirected] sample, but the parent byte count and elapsed time include all samples. The latency is taken from the initial response. Note that the HttpClient sampler may log the following message:

"Redirect requested but followRedirects is disabled"

This can be ignored. JMeter will collapse paths of the form '/../segment' in both absolute and relative redirect URLs. For example //host/one/../two will be collapsed into //host/two. If necessary, this behaviour can be suppressed by setting the JMeter propertyhttpsampler.redirect.removeslashdotdot=false

Use KeepAlive

JMeter sets the Connection: keep-alive header. This does not work properly with the default HTTP implementation, as connection re-use is not under user-control. It does work with the Apache HttpComponents HttpClient implementations.

Use multipart/form-data for HTTP POST

Use a multipart/form-data or application/x-www-form-urlencoded post request

Browser-compatible headers

When using multipart/form-data, this suppresses the Content-Type andContent-Transfer-Encoding headers; only the Content-Disposition header is sent.

Path

The path to resource [for example, /servlets/myServlet]. If the resource requires query string parameters, add them below in the "Send Parameters With the Request" section.

As a special case, if the path starts with "//" or "//" then this is used as the full URL.

In this case, the server, port and protocol fields are ignored; parameters are also ignored for GET and DELETE methods. Also please note that the path is not encoded - apart from replacing spaces with %20 - so unsafe characters may need to be encoded to avoid errors such as URISyntaxException.

Send Parameters With the Request

The query string will be generated from the list of parameters you provide. Each parameter has a name andvalue, the options to encode the parameter, and an option to include or exclude an equals sign [some applications don't expect an equals sign when the value is the empty string]. The query string will be generated in the correct fashion, depending on the choice of "Method" you made [i.e. if you chose GET or DELETE, the query string will be appended to the URL, if POST or PUT, then it will be sent separately]. Also, if you are sending a file using a multipart form, the query string will be created using the multipart form specifications. See below for some further information on parameter handling.

Additionally, you can specify whether each parameter should be URL encoded. If you are not sure what this means, it is probably best to select it. If your values contain characters such as the following then encoding is usually required.:

ASCII Control Chars
Non-ASCII characters
Reserved characters:URLs use some characters for special use in defining their syntax. When these characters are not used in their special role inside a URL, they need to be encoded, example: '$', '&', '+', ',' , '/', ':', ';', '\=', '?', '@'
Unsafe characters: Some characters present the possibility of being misunderstood within URLs for various reasons. These characters should also always be encoded, example: ' ', '', '#', '%', …

File Path:

Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request.

When MIME Type is empty, JMeter will try to guess the MIME type of the given file.

If it is a POST or PUT or PATCH request and there is a single file whose 'Parameter name' attribute [below] is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests, and also for PUT requests. See below for some further information on parameter handling.

Parameter name:

Value of the "name" web request parameter.

MIME Type

MIME type [for example, text/plain]. If it is a POST or PUT or PATCH request and either the 'name' attribute [below] are omitted or the request body is constructed from parameter values only, then the value of this field is used as the value of thecontent-type request header.

Retrieve All Embedded Resources from HTML Files

Tell JMeter to parse the HTML file and send HTTP/HTTPS requests for all images, Java applets, JavaScript files, CSSs, etc. referenced in the file. See below for more details.

Save response as MD5 hash?

If this is selected, then the response is not stored in the sample result. Instead, the 32 character MD5 hash of the data is calculated and stored instead. This is intended for testing large amounts of data.

URLs must match:

If present, this must be a regular expression that is used to match against any embedded URLs found. So if you only want to download embedded resources from //example.invalid/, use the expression://example\.invalid/.*

URLs must not match:

If present, this must be a regular expression that is used to filter out any embedded URLs found. So if you don't want to download PNG or SVG files from any source, use the expression:.*\.[?i:svg|png]

Use concurrent pool

Use a pool of concurrent connections to get embedded resources.

Size

Pool size for concurrent connections used to get embedded resources.

Source address type

[Only for HTTP Request with HTTPClient implementation] To distinguish the source address value, select the type of these:

Select IP/Hostname to use a specific IP address or a [local] hostname
Select Device to pick the first available address for that interface which this may be either IPv4 or IPv6
Select Device IPv4 to select the IPv4 address of the device name [like eth0, lo, em0, etc.]
Select Device IPv6 to select the IPv6 address of the device name [like eth0, lo, em0, etc.]

Source address field

[Only for HTTP Request with HTTPClient implementation] This property is used to enable IP Spoofing. It overrides the default local IP address for this sample. The JMeter host must have multiple IP addresses [i.e. IP aliases, network interfaces, devices]. The value can be a host name, IP address, or a network interface device such as "eth0" or "lo" or "wlan0". If the property httpclient.localaddress is defined, that is used for all HttpClient requests.

The following parameters are available only for GraphQL HTTP Request:

Parameters

Attribute

Description

Required

Query

GraphQL query [or mutation] statement.

Yes

Variables

GraphQL query [or mutation] variables in a valid JSON string. Note: If the input string is not a valid JSON string, this will be ignored with an ERROR log.

Operation Name

Optional GraphQL operation name when making a request for multi-operation documents.

When using Automatic Redirection, cookies are only sent for the initial URL. This can cause unexpected behaviour for web-sites that redirect to a local server. E.g. if www.example.com redirects to www.example.co.uk. In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last host, i.e. www.example.co.uk. If the next request in the test plan uses www.example.com, rather than www.example.co.uk, it will not get the correct cookies. Likewise, Headers are sent for the initial request, and won't be sent for the redirect. This is generally only a problem for manually created test plans, as a test plan created using a recorder would continue from the redirected URL.

Parameter Handling: For the POST and PUT method, if there is no file to send, and the name[s] of the parameter[s] are omitted, then the body is created by concatenating all the value[s] of the parameters. Note that the values are concatenated without adding any end-of-line characters. These can be added by using the function in the value fields. This allows arbitrary bodies to be sent. The values are encoded if the encoding flag is set. See also the MIME Type above how you can control the content-type request header that is sent. For other methods, if the name of the parameter is missing, then the parameter is ignored. This allows the use of optional parameters defined by variables.

You have the option to switch to Body Data tab when a request has only unnamed parameters [or no parameters at all]. This option is useful in the following cases [amongst others]:

GWT RPC HTTP Request
JSON REST HTTP Request
XML REST HTTP Request
SOAP HTTP Request

Note that once you leave the Tree node, you cannot switch back to the parameter tab unless you clear the Body Data tab from its data.

In Body Data mode, each line will be sent with CRLF appended, apart from the last line. To send a CRLF after the last line of data, just ensure that there is an empty line following it. [This cannot be seen, except by noting whether the cursor can be placed on the subsequent line.]

Figure 1 - HTTP Request with one unnamed parameter

Figure 2 - Confirm dialog to switch

Figure 3 - HTTP Request using Body Data

Method Handling: The GET, DELETE, POST, PUT and PATCH request methods work similarly, except that as of 3.1, only POST method supports multipart requests or file upload. The PUT and PATCH method body must be provided as one of the following:

define the body as a file with empty Parameter name field; in which case the MIME Type is used as the Content-Type
define the body as parameter value[s] with no name
use the Body Data tab

The GET, DELETE and POST methods have an additional way of passing parameters by using the Parameters tab.GET, DELETE, PUT and PATCH require a Content-Type. If not using a file, attach a Header Manager to the sampler and define the Content-Type there.

JMeter scan responses from embedded resources. It uses the property HTTPResponse.parsers, which is a list of parser ids, e.g. htmlParser, cssParser and wmlParser. For each id found, JMeter checks two further properties:

id.types - a list of content types
id.className - the parser to be used to extract the embedded resources

See jmeter.properties file for the details of the settings. If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour, i.e. only text/html responses will be scanned

Emulating slow connections:

HttpClient4 and Java Sampler support emulation of slow connections; see the following entries in jmeter.properties:

Define characters per second > 0 to emulate slow connections

httpclient.socket.http.cps=0

httpclient.socket.https.cps=0

However the Java sampler only supports slow HTTPS connections.

Response size calculation

The Java implementation does not include transport overhead such as chunk headers in the response body size. The HttpClient4 implementation does include the overhead in the response body size, so the value may be greater than the number of bytes in the response content.

Retry handling By default retry has been set to 0 for both HttpClient4 and Java implementations, meaning no retry is attempted. For HttpClient4, the retry count can be overridden by setting the relevant JMeter property, for example:

httpclient4.retrycount=3

With HC4 Implementation, retry will be done on Idempotent Http Methods by default. If you want to retry for all methods, then set property

httpclient4.request_sent_retry_enabled=true

Note that the Java implementation does not retry neither by default, you can change this by setting

http.java.sampler.retries=3

Note: Certificates does not conform to algorithm constraints You may encounter the following error: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints if you run a HTTPS request on a web site with a SSL certificate [itself or one of SSL certificates in its chain of trust] with a signature algorithm using MD2 [like md2WithRSAEncryption] or with a SSL certificate with a size lower than 1024 bits.

This error is related to increased security in Java 8.

To allow you to perform your HTTPS request, you can downgrade the security of your Java installation by editing the Java jdk.certpath.disabledAlgorithms property. Remove the MD2 value or the constraint on size, depending on your case.

This property is in this file:

JAVA_HOME/jre/lib/security/java.security

See Bug 56357 for details.

JDBC Request

This sampler lets you send a JDBC Request [an SQL query] to a database.

Before using this you need to set up a Configuration element

If the Variable Names list is provided, then for each row returned by a Select statement, the variables are set up with the value of the corresponding column [if a variable name is provided], and the count of rows is also set up. For example, if the Select statement returns 2 rows of 3 columns, and the variable list is A,,C, then the following variables will be set up:

A_#=2 [number of rows] A_1=column 1, row 1 A_2=column 1, row 2 C_#=2 [number of rows] C_1=column 3, row 1 C_2=column 3, row 2

If the Select statement returns zero rows, then the A_# and C_# variables would be set to 0, and no other variables would be set.

Old variables are cleared if necessary - e.g. if the first select retrieves six rows and a second select returns only three rows, the additional variables for rows four, five and six will be removed.

The latency time is set from the time it took to acquire a connection.

Screenshot of Control-Panel of JDBC Request

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Variable Name of Pool declared in JDBC Connection Configuration

Name of the JMeter variable that the connection pool is bound to. This must agree with the 'Variable Name' field of a .

Yes

Query Type

Set this according to the statement type:

Select Statement
Update Statement - use this for Inserts and Deletes as well
Callable Statement
Prepared Select Statement
Prepared Update Statement - use this for Inserts and Deletes as well
Commit
Rollback
Autocommit[false]
Autocommit[true]
Edit - this should be a variable reference that evaluates to one of the above

The types Commit, Rollback, Autocommit[false] and Autocommit[true] are special, as they are ignoring the given SQL statements and are changing the state of the connection, only.

Yes

SQL Query

SQL query.

Do not enter a trailing semi-colon.

There is generally no need to use { and } to enclose Callable statements; however they may be used if the database uses a non-standard syntax.

The JDBC driver automatically converts the statement if necessary when it is enclosed in {}.

For example:

select * from t_customers where id=23
CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE [null, ?, ?, null, null, null]
- Parameter values: tablename,filename
- Parameter types: VARCHAR,VARCHAR

The second example assumes you are using Apache Derby.

Yes

Parameter values

Comma-separated list of parameter values. Use ]NULL[ to indicate a NULL parameter. [If required, the null string can be changed by defining the property "jdbcsampler.nullmarker".] The list must be enclosed in double-quotes if any of the values contain a comma or double-quote, and any embedded double-quotes must be doubled-up, for example:

httpclient.reset_state_on_thread_group_iteration=true

There must be as many values as there are placeholders in the statement even if your parameters are OUT ones. Be sure to set a value even if the value will not be used [for example in a CallableStatement].

Yes, if a prepared or callable statement has parameters

Parameter types

Comma-separated list of SQL parameter types [e.g. INTEGER, DATE, VARCHAR, DOUBLE] or integer values of Constants. Those integer values can be used, when you use custom database types proposed by driver [For example OracleTypes.CURSOR could be represented by its integer value -10]. These are defined as fields in the class java.sql.Types, see for example: Javadoc for java.sql.Types.

Note: JMeter will use whatever types are defined by the runtime JVM, so if you are running on a different JVM, be sure to check the appropriate documentation

If the callable statement has INOUT or OUT parameters, then these must be indicated by prefixing the appropriate parameter types, e.g. instead of "INTEGER", use "INOUT INTEGER". If not specified, "IN" is assumed, i.e. "DATE" is the same as "IN DATE". If the type is not one of the fields found in java.sql.Types, JMeter also accepts the corresponding integer number, e.g. since OracleTypes.CURSOR == -10, you can use "INOUT -10". There must be as many types as there are placeholders in the statement.

Yes, if a prepared or callable statement has parameters

Variable Names

Comma-separated list of variable names to hold values returned by Select statements, Prepared Select Statements or CallableStatement. Note that when used with CallableStatement, list of variables must be in the same sequence as the OUT parameters returned by the call. If there are less variable names than OUT parameters only as many results shall be stored in the thread-context variables as variable names were supplied. If more variable names than OUT parameters exist, the additional variables will be ignored

Result Variable Name

If specified, this will create an Object variable containing a list of row maps. Each map contains the column name as the key and the column data as the value. Usage:

httpclient.reset_state_on_thread_group_iteration=true

Query timeout[s]

Set a timeout in seconds for query, empty value means 0 which is infinite. -1 means don't set any query timeout which might be needed for use case or when certain drivers don't support timeout. Defaults to 0.

Limit ResultSet

Limits the number of rows to iterate through the ResultSet. Empty value means -1, e.g. no limitation, which is also the default. This can help to reduce the amount of data to be fetched from the database via the JDBC driver, but affects all possible options of Handle ResultSet respectively – e.g. incomplete ResultSet and a record count ≤ the limit.

Handle ResultSet

Defines how ResultSet returned from callable statements be handled:

Store As String [default] - All variables on Variable Names list are stored as strings, will not iterate through a ResultSet when present on the list. CLOBs will be converted to Strings. BLOBs will be converted to Strings as if they were an UTF-8 encoded byte-array. Both CLOBs and BLOBs will be cut off after jdbcsampler.max_retain_result_size bytes.
Store As Object - Variables of ResultSet type on Variables Names list will be stored as Object and can be accessed in subsequent tests/scripts and iterated, will not iterate through the ResultSet. CLOBs will be handled as if Store As String was selected. BLOBs will be stored as a byte array. Both CLOBs and BLOBs will be cut off after jdbcsampler.max_retain_result_size bytes.
Count Records - Variables of ResultSet types will be iterated through showing the count of records as result. Variables will be stored as Strings. For BLOBs the size of the object will be stored.

Current Versions of JMeter use UTF-8 as the character encoding. Previously the platform default was used.

Ensure Variable Name is unique across Test Plan.

Java Request

This sampler lets you control a java class that implements theorg.apache.jmeter.protocol.java.sampler.JavaSamplerClient interface. By writing your own implementation of this interface, you can use JMeter to harness multiple threads, input parameter control, and data collection.

The pull-down menu provides the list of all such implementations found by JMeter in its classpath. The parameters can then be specified in the table below - as defined by your implementation. Two simple examples [JavaTest and SleepTest] are provided.

The JavaTest example sampler can be useful for checking test plans, because it allows one to set values in almost all the fields. These can then be used by Assertions, etc. The fields allow variables to be used, so the values of these can readily be seen.

Screenshot of Control-Panel of Java Request

If the method teardownTest is not overridden by a subclass of AbstractJavaSamplerClient, its teardownTest method will not be called. This reduces JMeter memory requirements. This will not have any impact on existing Test plans.

The Add/Delete buttons don't serve any purpose at present.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Classname

The specific implementation of the JavaSamplerClient interface to be sampled.

Yes

Send Parameters with Request

A list of arguments that will be passed to the sampled class. All arguments are sent as Strings. See below for specific settings.

The following parameters apply to the SleepTest and JavaTest implementations:

Parameters

Attribute

Description

Required

Sleep_time

How long to sleep for [ms]

Yes

Sleep_mask

How much "randomness" to add: The sleep time is calculated as follows:

httpclient.reset_state_on_thread_group_iteration=true

Yes

The following parameters apply additionally to the JavaTest implementation:

Parameters

Attribute

Description

Required

Label

The label to use. If provided, overrides Name

ResponseCode

If provided, sets the SampleResult ResponseCode.

ResponseMessage

If provided, sets the SampleResult ResponseMessage.

Status

If provided, sets the SampleResult Status. If this equals "OK" [ignoring case] then the status is set to success, otherwise the sample is marked as failed.

SamplerData

If provided, sets the SampleResult SamplerData.

ResultData

If provided, sets the SampleResult ResultData.

LDAP Request

This Sampler lets you send a different LDAP request[Add, Modify, Delete and Search] to an LDAP server.

If you are going to send multiple requests to the same LDAP server, consider using an Configuration Element so you do not have to enter the same information for each LDAP Request.

The same way the also using for Login and password.

Screenshot of Control-Panel of LDAP Request

There are two ways to create test cases for testing an LDAP Server.

Inbuilt Test cases.
User defined Test cases.

There are four test scenarios of testing LDAP. The tests are given below:

Add Test
1. Inbuilt test: This will add a pre-defined entry in the LDAP Server and calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server.
2. User defined test: This will add the entry in the LDAP Server. User has to enter all the attributes in the table.The entries are collected from the table to add. The execution time is calculated. The created entry will not be deleted after the test.
Modify Test
1. Inbuilt test: This will create a pre-defined entry first, then will modify the created entry in the LDAP Server.And calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server.
2. User defined test: This will modify the entry in the LDAP Server. User has to enter all the attributes in the table. The entries are collected from the table to modify. The execution time is calculated. The entry will not be deleted from the LDAP Server.
Search Test
1. Inbuilt test: This will create the entry first, then will search if the attributes are available. It calculates the execution time of the search query. At the end of the execution,created entry will be deleted from the LDAP Server.
2. User defined test: This will search the user defined entry[Search filter] in the Search base [again, defined by the user]. The entries should be available in the LDAP Server. The execution time is calculated.
Delete Test
1. Inbuilt test: This will create a pre-defined entry first, then it will be deleted from the LDAP Server. The execution time is calculated.
2. User defined test: This will delete the user-defined entry in the LDAP Server. The entries should be available in the LDAP Server. The execution time is calculated.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Server Name or IP

Domain name or IP address of the LDAP server. JMeter assumes the LDAP server is listening on the default port [389].

Yes

Port

Port to connect to [default is 389].

Yes

root DN

Base DN to use for LDAP operations

Yes

Username

LDAP server username.

Usually

Password

LDAP server password. [N.B. this is stored unencrypted in the test plan]

Usually

Entry DN

the name of the context to create or Modify; may not be empty.

You have to set the right attributes of the object yourself. So if you want to add cn=apache,ou=test you have to add in the table name and value to cn and apache.

Yes, if User Defined Test and Add Test or Modify Test is selected

Delete

the name of the context to Delete; may not be empty

Yes, if User Defined Test and Delete Test is selected

Search base

the name of the context or object to search

Yes, if User Defined Test and Search Test is selected

Search filter

the filter expression to use for the search; may not be null

Yes, if User Defined Test and Search Test is selected

add test

Use these name, value pairs for creation of the new object in the given context

Yes, if User Defined Test and add Test is selected

modify test

Use these name, value pairs for modification of the given context object

Yes, if User Defined Test and Modify Test is selected

LDAP Extended Request

This Sampler can send all 8 different LDAP requests to an LDAP server. It is an extended version of the LDAP sampler, therefore it is harder to configure, but can be made much closer resembling a real LDAP session.

If you are going to send multiple requests to the same LDAP server, consider using an Configuration Element so you do not have to enter the same information for each LDAP Request.

Screenshot of Control-Panel of LDAP Extended Request

There are nine test operations defined. These operations are given below:

Thread bind

Any LDAP request is part of an LDAP session, so the first thing that should be done is starting a session to the LDAP server. For starting this session a thread bind is used, which is equal to the LDAP "bind" operation. The user is requested to give a username [Distinguished name] and password, which will be used to initiate a session. When no password, or the wrong password is specified, an anonymous session is started. Take care, omitting the password will not fail this test, a wrong password will. [N.B. this is stored unencrypted in the test plan]

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Servername

The name [or IP-address] of the LDAP server.

Yes

Port

The port number that the LDAP server is listening to. If this is omitted JMeter assumes the LDAP server is listening on the default port[389].

The distinguished name of the base object that will be used for any subsequent operation. It can be used as a starting point for all operations. You cannot start any operation on a higher level than this DN!

Username

Full distinguished name of the user as which you want to bind.

Password

Password for the above user. If omitted it will result in an anonymous bind. If it is incorrect, the sampler will return an error and revert to an anonymous bind. [N.B. this is stored unencrypted in the test plan]

Connection timeout [in milliseconds]

Timeout for connection, if exceeded connection will be aborted

Use Secure LDAP Protocol

Use ldaps:// scheme instead of ldap://

Trust All Certificates

Trust all certificates, only used if Use Secure LDAP Protocol is checked

Thread unbind

This is simply the operation to end a session. It is equal to the LDAP "unbind" operation.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Single bind/unbind

This is a combination of the LDAP "bind" and "unbind" operations. It can be used for an authentication request/password check for any user. It will open a new session, just to check the validity of the user/password combination, and end the session again.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Username

Full distinguished name of the user as which you want to bind.

Yes

Password

Password for the above user. If omitted it will result in an anonymous bind. If it is incorrect, the sampler will return an error. [N.B. this is stored unencrypted in the test plan]

Rename entry

This is the LDAP "moddn" operation. It can be used to rename an entry, but also for moving an entry or a complete subtree to a different place in the LDAP tree.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Old entry name

The current distinguished name of the object you want to rename or move, relative to the given DN in the thread bind operation.

Yes

New distinguished name

The new distinguished name of the object you want to rename or move, relative to the given DN in the thread bind operation.

Yes

Add test

This is the LDAP "add" operation. It can be used to add any kind of object to the LDAP server.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Entry DN

Distinguished name of the object you want to add, relative to the given DN in the thread bind operation.

Yes

Add test

A list of attributes and their values you want to use for the object. If you need to add a multiple value attribute, you need to add the same attribute with their respective values several times to the list.

Yes

Delete test

This is the LDAP "delete" operation, it can be used to delete an object from the LDAP tree

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Delete

Distinguished name of the object you want to delete, relative to the given DN in the thread bind operation.

Yes

Search test

This is the LDAP "search" operation, and will be used for defining searches.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Search base

Distinguished name of the subtree you want your search to look in, relative to the given DN in the thread bind operation.

Search Filter

searchfilter, must be specified in LDAP syntax.

Yes

Scope

Use 0 for baseobject-, 1 for onelevel- and 2 for a subtree search. [Default=0]

Size Limit

Specify the maximum number of results you want back from the server. [default=0, which means no limit.] When the sampler hits the maximum number of results, it will fail with errorcode 4

Time Limit

Specify the maximum amount of [cpu]time [in milliseconds] that the server can spend on your search. Take care, this does not say anything about the response time. [default is 0, which means no limit]

Attributes

Specify the attributes you want to have returned, separated by a semicolon. An empty field will return all attributes

Return object

Whether the object will be returned [true] or not [false]. Default=false

Dereference aliases

If true, it will dereference aliases, if false, it will not follow them [default=false]

Parse the search results?

If true, the search results will be added to the response data. If false, a marker - whether results where found or not - will be added to the response data.

Modification test

This is the LDAP "modify" operation. It can be used to modify an object. It can be used to add, delete or replace values of an attribute.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Entry name

Distinguished name of the object you want to modify, relative to the given DN in the thread bind operation

Yes

Modification test

The attribute-value-opCode triples. The opCode can be any valid LDAP operationCode [add, delete, remove or replace]. If you don't specify a value with a delete operation, all values of the given attribute will be deleted. If you do specify a value in a delete operation, only the given value will be deleted. If this value is non-existent, the sampler will fail the test.

Yes

Compare

This is the LDAP "compare" operation. It can be used to compare the value of a given attribute with some already known value. In reality this is mostly used to check whether a given person is a member of some group. In such a case you can compare the DN of the user as a given value, with the values in the attribute "member" of an object of the type groupOfNames. If the compare operation fails, this test fails with errorcode 49.

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Entry DN

The current distinguished name of the object of which you want to compare an attribute, relative to the given DN in the thread bind operation.

Yes

Compare filter

In the form "attribute=value"

Yes

Access Log Sampler

AccessLogSampler was designed to read access logs and generate http requests. For those not familiar with the access log, it is the log the webserver maintains of every request it accepted. This means every image, CSS file, JavaScript file, html file, …

Tomcat uses the common format for access logs. This means any webserver that uses the common log format can use the AccessLogSampler. Server that use common log format include: Tomcat, Resin, Weblogic, and SunOne. Common log format looks like this:

httpclient.reset_state_on_thread_group_iteration=true

The current implementation of the parser only looks at the text within the quotes that contains one of the HTTP protocol methods [GET, PUT, POST, DELETE, …]. Everything else is stripped out and ignored. For example, the response code is completely ignored by the parser.

For the future, it might be nice to filter out entries that do not have a response code of 200. Extending the sampler should be fairly simple. There are two interfaces you have to implement:

org.apache.jmeter.protocol.http.util.accesslog.LogParser
org.apache.jmeter.protocol.http.util.accesslog.Generator

The current implementation of AccessLogSampler uses the generator to create a new HTTPSampler. The servername, port and get images are set by AccessLogSampler. Next, the parser is called with integer 1, telling it to parse one entry. After that,HTTPSampler.sample[] is called to make the request.

httpclient.reset_state_on_thread_group_iteration=true

The required methods in LogParser are:

setGenerator[Generator]
parse[int]

Classes implementing Generator interface should provide concrete implementation for all the methods. For an example of how to implement either interface, refer toStandardGenerator and TCLogParser.

Screenshot of Control-Panel of Access Log Sampler

[Beta Code]

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Server

Domain name or IP address of the web server.

Yes

Protocol

Scheme

No [defaults to http

Port

Port the web server is listening to.

No [defaults to 80]

Log parser class

The log parser class is responsible for parsing the logs.

Yes [default provided]

Filter

The filter class is used to filter out certain lines.

Location of log file

The location of the access log file.

Yes

The TCLogParser processes the access log independently for each thread. The SharedTCLogParser and OrderPreservingLogParser share access to the file, i.e. each thread gets the next entry in the log.

The SessionFilter is intended to handle Cookies across threads. It does not filter out any entries, but modifies the cookie manager so that the cookies for a given IP are processed by a single thread at a time. If two threads try to process samples from the same client IP address, then one will be forced to wait until the other has completed.

The LogFilter is intended to allow access log entries to be filtered by filename and regex, as well as allowing for the replacement of file extensions. However, it is not currently possible to configure this via the GUI, so it cannot really be used.

BeanShell Sampler

This sampler allows you to write a sampler using the BeanShell scripting language.

For full details on using BeanShell, please see the BeanShell website.

Migration to +Groovy is highly recommended for performance, support of new Java features and limited maintenance of the BeanShell library.

The test element supports the ThreadListener and TestListener interface methods. These must be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.

The BeanShell sampler also supports the Interruptible interface. The interrupt[] method can be defined in the script or the init file.

Screenshot of Control-Panel of BeanShell Sampler

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree. The name is stored in the script variable Label

Reset bsh.Interpreter before each call

If this option is selected, then the interpreter will be recreated for each sample. This may be necessary for some long running scripts. For further information, see .

Yes

Parameters

Parameters to pass to the BeanShell script. This is intended for use with script files; for scripts defined in the GUI, you can use whatever variable and function references you need within the script itself. The parameters are stored in the following variables:

Parametersstring containing the parameters as a single variablebsh.argsString array containing parameters, split on white-space

Script file

A file containing the BeanShell script to run. The file name is stored in the script variable FileName

Script

The BeanShell script to run. The return value [if not null] is stored as the sampler result.

Yes [unless script file is provided]

N.B. Each Sampler instance has its own BeanShell interpreter, and Samplers are only called from a single thread

If the property "beanshell.sampler.init" is defined, it is passed to the Interpreter as the name of a sourced file. This can be used to define common methods and variables. There is a sample init file in the bin directory: BeanShellSampler.bshrc.

If a script file is supplied, that will be used, otherwise the script will be used.

JMeter processes function and variable references before passing the script field to the interpreter, so the references will only be resolved once. Variable and function references in script files will be passed verbatim to the interpreter, which is likely to cause a syntax error. In order to use runtime variables, please use the appropriate props methods, e.g.props.get["START.HMS"]; props.put["PROP1","1234"]; BeanShell does not currently support Java 5 syntax such as generics and the enhanced for loop.

Before invoking the script, some variables are set up in the BeanShell interpreter:

The contents of the Parameters field is put into the variable "Parameters". The string is also split into separate tokens using a single space as the separator, and the resulting list is stored in the String array bsh.args.

The full list of BeanShell variables that is set up is as follows:

log - the Logger
Label - the Sampler label
FileName - the file name, if any
Parameters - text from the Parameters field
bsh.args - the parameters, split as described above
SampleResult - pointer to the current SampleResult
ResponseCode defaults to 200
ResponseMessage defaults to "OK"
IsSuccess defaults to true
ctx - JMeterContext
vars - JMeterVariables - e.g. httpclient.reset_state_on_thread_group_iteration=true 5
props - JMeterProperties [class java.util.Properties] - e.g. httpclient.reset_state_on_thread_group_iteration=true 6

When the script completes, control is returned to the Sampler, and it copies the contents of the following script variables into the corresponding variables in the SampleResult:

ResponseCode - for example 200
ResponseMessage - for example "OK"
IsSuccess - true or false

The SampleResult ResponseData is set from the return value of the script. If the script returns null, it can set the response directly, by using the methodSampleResult.setResponseData[data], where data is either a String or a byte array. The data type defaults to "text", but can be set to binary by using the methodSampleResult.setDataType[SampleResult.BINARY].

The SampleResult variable gives the script full access to all the fields and methods in the SampleResult. For example, the script has access to the methodssetStopThread[boolean] and setStopTest[boolean]. Here is a simple [not very useful!] example script:

httpclient.reset_state_on_thread_group_iteration=true

Another example: ensure that the property beanshell.sampler.init=BeanShellSampler.bshrc is defined in jmeter.properties. The following script will show the values of all the variables in the ResponseData field:

httpclient.reset_state_on_thread_group_iteration=true

For details on the methods available for the various classes [JMeterVariables, SampleResult etc.] please check the Javadoc or the source code. Beware however that misuse of any methods can cause subtle faults that may be difficult to find.

JSR223 Sampler

The JSR223 Sampler allows JSR223 script code to be used to perform a sample or some computation required to create/update variables.

If you don't want to generate a SampleResult when this sampler is run, call the following method:

httpclient.reset_state_on_thread_group_iteration=true

This call will have the following impact:

SampleResult will not be delivered to SampleListeners like View Results Tree, Summariser ...
SampleResult will not be evaluated in Assertions nor PostProcessors
SampleResult will be evaluated to computing last sample status [${JMeterThread.last_sample_ok}], and ThreadGroup "Action to be taken after a Sampler error" [since JMeter 5.4]

The JSR223 test elements have a feature [compilation] that can significantly increase performance. To benefit from this feature:

Use Script files instead of inlining them. This will make JMeter compile them if this feature is available on ScriptEngine and cache them.
Or Use Script Text and check Cache compiled script if available property.
When using this feature, ensure your script code does not use JMeter variables or JMeter function calls directly in script code as caching would only cache first replacement. Instead use script parameters. To benefit from caching and compilation, the language engine used for scripting must implement JSR223 Compilable interface [Groovy is one of these, java, beanshell and javascript are not] When using Groovy as scripting language and not checking Cache compiled script if available [while caching is recommended], you should set this JVM Property -Dgroovy.use.classvalue=true due to a Groovy Memory leak as of version 2.4.6, see:
- GROOVY-7683
- GROOVY-7591
- JDK-8136353

Cache size is controlled by the following JMeter property [jmeter.properties]:

https.default.protocol=SSLv3

Unlike the , the interpreter is not saved between invocations.

JSR223 Test Elements using Script file or Script text + checked Cache compiled script if available are now compiled if ScriptEngine supports this feature, this enables great performance enhancements.

Screenshot of Control-Panel of JSR223 Sampler

httpclient.reset_state_on_thread_group_iteration=true

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Scripting Language

Name of the JSR223 scripting language to be used.

There are other languages supported than those that appear in the drop-down list. Others may be available if the appropriate jar is installed in the JMeter lib directory. Notice that some languages such as Velocity may use a different syntax for JSR223 variables, e.g.

https.default.protocol=SSLv3

for Velocity.

Yes

Script File

Name of a file to be used as a JSR223 script, if a relative file path is used, then it will be relative to directory referenced by "user.dir" System property

Parameters

List of parameters to be passed to the script file or the script.

Cache compiled script if available

If checked [advised] and the language used supports Compilable interface [Groovy is one of these, java, beanshell and javascript are not], JMeter will compile the Script and cache it using its MD5 hash as unique cache key

Script

Script to be passed to JSR223 language

Yes [unless script file is provided]

If a script file is supplied, that will be used, otherwise the script will be used.

Before invoking the script, some variables are set up. Note that these are JSR223 variables - i.e. they can be used directly in the script.

log - the Logger
Label - the Sampler label
FileName - the file name, if any
Parameters - text from the Parameters field
args - the parameters, split as described above
SampleResult - pointer to the current SampleResult
sampler - [Sampler] - pointer to current Sampler
ctx - JMeterContext
vars - JMeterVariables - e.g. httpclient.reset_state_on_thread_group_iteration=true 5
props - JMeterProperties [class java.util.Properties] - e.g. httpclient.reset_state_on_thread_group_iteration=true 6
OUT - System.out - e.g. OUT.println["message"]

Unlike the BeanShell Sampler, the JSR223 Sampler does not set the ResponseCode, ResponseMessage and sample status via script variables. Currently the only way to changes these is via the SampleResult methods:

SampleResult.setSuccessful[true/false]
SampleResult.setResponseCode["code"]
SampleResult.setResponseMessage["message"]

TCP Sampler

The TCP Sampler opens a TCP/IP connection to the specified server. It then sends the text, and waits for a response.

If "Re-use connection" is selected, connections are shared between Samplers in the same thread, provided that the exact same host name string and port are used. Different hosts/port combinations will use different connections, as will different threads. If both of "Re-use connection" and "Close connection" are selected, the socket will be closed after running the sampler. On the next sampler, another socket will be created. You may want to close a socket at the end of each thread loop.

If an error is detected - or "Re-use connection" is not selected - the socket is closed. Another socket will be reopened on the next sample.

The following properties can be used to control its operation:

tcp.status.prefixtext that precedes a status numbertcp.status.suffixtext that follows a status numbertcp.status.propertiesname of property file to convert status codes to messagestcp.handlerName of TCP Handler class [default TCPClientImpl] - only used if not specified on the GUI

The class that handles the connection is defined by the GUI, failing that the property tcp.handler. If not found, the class is then searched for in the package org.apache.jmeter.protocol.tcp.sampler.

Users can provide their own implementation. The class must extend org.apache.jmeter.protocol.tcp.sampler.TCPClient.

The following implementations are currently provided.

TCPClientImpl
BinaryTCPClientImpl
LengthPrefixedBinaryTCPClientImpl

The implementations behave as follows:

TCPClientImpl This implementation is fairly basic. When reading the response, it reads until the end of line byte, if this is defined by setting the property tcp.eolByte, otherwise until the end of the input stream. You can control charset encoding by setting tcp.charset, which will default to Platform default encoding.BinaryTCPClientImpl This implementation converts the GUI input, which must be a hex-encoded string, into binary, and performs the reverse when reading the response. When reading the response, it reads until the end of message byte, if this is defined by setting the property tcp.BinaryTCPClient.eomByte, otherwise until the end of the input stream.LengthPrefixedBinaryTCPClientImpl This implementation extends BinaryTCPClientImpl by prefixing the binary message data with a binary length byte. The length prefix defaults to 2 bytes. This can be changed by setting the property tcp.binarylength.prefix.length. Timeout handling If the timeout is set, the read will be terminated when this expires. So if you are using an eolByte/eomByte, make sure the timeout is sufficiently long, otherwise the read will be terminated early. Response handling If tcp.status.prefix is defined, then the response message is searched for the text following that up to the suffix. If any such text is found, it is used to set the response code. The response message is then fetched from the properties file [if provided].

Usage of pre- and suffix

For example, if the prefix = "[" and the suffix = "]", then the following response:

https.default.protocol=SSLv3

would have the response code J28.

Response codes in the range "400"-"499" and "500"-"599" are currently regarded as failures; all others are successful. [This needs to be made configurable!]

The login name/password are not used by the supplied TCP implementations.

Sockets are disconnected at the end of a test run.

Screenshot of Control-Panel of TCP Sampler

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

TCPClient classname

Name of the TCPClient class. Defaults to the property tcp.handler, failing that TCPClientImpl.

ServerName or IP

Name or IP of TCP server

Yes

Port Number

Port to be used

Yes

Re-use connection

If selected, the connection is kept open. Otherwise it is closed when the data has been read.

Yes

Close connection

If selected, the connection will be closed after running the sampler.

Yes

SO_LINGER

Enable/disable SO_LINGER with the specified linger time in seconds when a socket is created. If you set "SO_LINGER" value as 0, you may prevent large numbers of sockets sitting around with a TIME_WAIT status.

End of line[EOL] byte value

Byte value for end of line, set this to a value outside the range -128 to +127 to skip eol checking. You may set this in jmeter.properties file as well with eolByte property. If you set this in TCP Sampler Config and in jmeter.properties file at the same time, the setting value in the TCP Sampler Config will be used.

Connect Timeout

Connect Timeout [milliseconds, 0 disables].

Response Timeout

Response Timeout [milliseconds, 0 disables].

Set NoDelay

See java.net.Socket.setTcpNoDelay[]. If selected, this will disable Nagle's algorithm, otherwise Nagle's algorithm will be used.

Yes

Text to Send

Text to be sent

Yes

User Name - not used by default implementation

Password

Password - not used by default implementation [N.B. this is stored unencrypted in the test plan]

JMS Publisher

JMS Publisher will publish messages to a given destination [topic/queue]. For those not familiar with JMS, it is the J2EE specification for messaging. There are numerous JMS servers on the market and several open source options.

JMeter does not include any JMS implementation jar; this must be downloaded from the JMS provider and put in the lib directory

Screenshot of Control-Panel of JMS Publisher

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

use JNDI properties file

use jndi.properties. Note that the file must be on the classpath - e.g. by updating the user.classpath JMeter property. If this option is not selected, JMeter uses the "JNDI Initial Context Factory" and "Provider URL" fields to create the connection.

Yes

JNDI Initial Context Factory

Name of the context factory

Provider URL

The URL for the JMS provider

Yes, unless using jndi.properties

Destination

The message destination [topic or queue name]

Yes

Setup

The destination setup type. With At startup, the destination name is static [i.e. always same name during the test], with Each sample, the destination name is dynamic and is evaluate at each sample [i.e. the destination name may be a variable]

Yes

Authentication

Authentication requirement for the JMS provider

Yes

Password

Password [N.B. this is stored unencrypted in the test plan]

Expiration

The expiration time [in milliseconds] of the message before it becomes obsolete. If you do not specify an expiration time, the default value is 0 [never expires].

Priority

The priority level of the message. There are ten priority levels from 0 [lowest] to 9 [highest]. If you do not specify a priority level, the default level is 4.

Reconnect on error codes [regex]

Regular expression for JMSException error codes which force reconnection. If empty no reconnection will be done

Number of samples to aggregate

Yes

Message source

Where to obtain the message:

From Filemeans the referenced file will be read and reused by all samples. If file name changes it is reloaded since JMeter 3.0Random File from folder specified belowmeans a random file will be selected from folder specified below, this folder must contain either files with extension .dat for Bytes Messages, or files with extension .txt or .obj for Object or Text messagesText areaThe Message to use either for Text or Object message

Yes

Message type

Text, Map, Object message or Bytes Message

Yes

Content encoding

Specify the encoding for reading the message source file:

RAW: No variable support from the file and load it with default system charset.DEFAULT: Load file with default system encoding, except for XML which relies on XML prolog. If the file contain variables, they will be processed.Standard charsets: The specified encoding [valid or not] is used for reading the file and processing variables

Yes

Use non-persistent delivery mode?

Whether to set DeliveryMode.NON_PERSISTENT [defaults to false]

JMS Properties

The JMS Properties are properties specific for the underlying messaging system. You can setup the name, the value and the class [type] of value. Default type is String. For example: for WebSphere 5.1 web services you will need to set the JMS Property targetService to test webservices through JMS.

For the MapMessage type, JMeter reads the source as lines of text. Each line must have 3 fields, delimited by commas. The fields are:

Name of entry
Object class name, e.g. "String" [assumes java.lang package if not specified]
Object string value

valueOf[String]

https.default.protocol=SSLv3

The Object message is implemented and works as follow:

Put the JAR that contains your object and its dependencies in jmeter_home/lib/ folder
Serialize your object as XML using XStream
Either put result in a file suffixed with .txt or .obj or put XML content directly in Text Area

Note that if message is in a file, replacement of properties will not occur while it will if you use Text Area.

The following table shows some values which may be useful when configuring JMS:

Apache ActiveMQ Value[s] Comment Context Factoryorg.apache.activemq.jndi.ActiveMQInitialContextFactory. Provider URLvm://localhostProvider URLvm:[broker:[vm://localhost]?persistent=false]Disable persistence Queue ReferencedynamicQueues/QUEUENAME the QUEUENAME to JNDI Topic ReferencedynamicTopics/TOPICNAME the TOPICNAME to JNDI

JMS Subscriber

JMS Subscriber will subscribe to messages in a given destination [topic or queue]. For those not familiar with JMS, it is the J2EE specification for messaging. There are numerous JMS servers on the market and several open source options.

JMeter does not include any JMS implementation jar; this must be downloaded from the JMS provider and put in the lib directory

Screenshot of Control-Panel of JMS Subscriber

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

use JNDI properties file

Yes

JNDI Initial Context Factory

Name of the context factory

Provider URL

The URL for the JMS provider

Destination

the message destination [topic or queue name]

Yes

Durable Subscription ID

The ID to use for a durable subscription. On first use the respective queue will automatically be generated by the JMS provider if it does not exist yet.

Client ID

The Client ID to use when you use a durable subscription. Be sure to add a variable like ${__threadNum} when you have more than one Thread.

JMS Selector

Message Selector as defined by JMS specification to extract only messages that respect the Selector condition. Syntax uses subpart of SQL 92.

Setup

The destination setup type. With At startup, the destination name is static [i.e. always same name during the test], with Each sample, the destination name is dynamic and is evaluated at each sample [i.e. the destination name may be a variable]

Yes

Authentication

Authentication requirement for the JMS provider

Yes

Password

Password [N.B. this is stored unencrypted in the test plan]

Number of samples to aggregate

number of samples to aggregate

Yes

Save response

should the sampler store the response. If not, only the response length is returned.

Yes

Timeout

Specify the timeout to be applied, in milliseconds. 0\=none. This is the overall aggregate timeout, not per sample.

Yes

Client

Which client implementation to use. Both of them create connections which can read messages. However they use a different strategy, as described below:

MessageConsumer.receive[]calls receive[] for every requested message. Retains the connection between samples, but does not fetch messages unless the sampler is active. This is best suited to Queue subscriptions.MessageListener.onMessage[]establishes a Listener that stores all incoming messages on a queue. The listener remains active after the sampler completes. This is best suited to Topic subscriptions.

Yes

Stop between samples?

If selected, then JMeter calls Connection.stop[] at the end of each sample [and calls start[] before each sample]. This may be useful in some cases where multiple samples/threads have connections to the same queue. If not selected, JMeter calls Connection.start[] at the start of the thread, and does not call stop[] until the end of the thread.

Yes

Separator

Separator used to separate messages when there is more than one [related to setting Number of samples to aggregate]. Note that \n, \r, \t are accepted.

Reconnect on error codes [regex]

Regular expression for JMSException error codes which force reconnection. If empty no reconnection will be done

Pause between errors [ms]

Pause in milliseconds that Subscriber will make when an error occurs

JMS Point-to-Point

This sampler sends and optionally receives JMS Messages through point-to-point connections [queues]. It is different from pub/sub messages and is generally used for handling transactions.

request_only will typically be used to put load on a JMS System. request_reply will be used when you want to test response time of a JMS service that processes messages sent to the Request Queue as this mode will wait for the response on the Reply queue sent by this service. browse returns the current queue depth, i.e. the number of messages on the queue. read reads a message from the queue [if any]. clear clears the queue, i.e. remove all messages from the queue.

JMeter use the properties java.naming.security.[principal|credentials] - if present - when creating the Queue Connection. If this behaviour is not desired, set the JMeter propertyJMSSampler.useSecurity.properties=false

JMeter does not include any JMS implementation jar; this must be downloaded from the JMS provider and put in the lib directory

Screenshot of Control-Panel of JMS Point-to-Point

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

QueueConnection Factory

The JNDI name of the queue connection factory to use for connecting to the messaging system.

Yes

JNDI Name Request queue

This is the JNDI name of the queue to which the messages are sent.

Yes

JNDI Name Reply queue

The JNDI name of the receiving queue. If a value is provided here and the communication style is Request Response this queue will be monitored for responses to the requests sent.

Number of samples to aggregate

Number of samples to aggregate. Only applicable for Communication style Read.

Yes

JMS Selector

Message Selector as defined by JMS specification to extract only messages that respect the Selector condition. Syntax uses subpart of SQL 92.

Communication style

The Communication style can be Request Only [also known as Fire and Forget], Request Response,Read, Browse, Clear:

Request Only will only send messages and will not monitor replies. As such it can be used to put load on a system.Request Response will send messages and monitor the replies it receives. Behaviour depends on the value of the JNDI Name Reply Queue. If JNDI Name Reply Queue has a value, this queue is used to monitor the results. Matching of request and reply is done with the message id of the request and the correlation id of the reply. If the JNDI Name Reply Queue is empty, then temporary queues will be used for the communication between the requestor and the server. This is very different from the fixed reply queue. With temporary queues the sending thread will block until the reply message has been received. With Request Response mode, you need to have a Server that listens to messages sent to Request Queue and sends replies to queue referenced by message.getJMSReplyTo[].Read will read a message from an outgoing queue which has no listeners attached. This can be convenient for testing purposes. This method can be used if you need to handle queues without a binding file [in case the jmeter-jms-skip-jndi library is used], which only works with the JMS Point-to-Point sampler. In case binding files are used, one can also use the JMS Subscriber Sampler for reading from a queue.Browse will determine the current queue depth without removing messages from the queue, returning the number of messages on the queue.Clear will clear the queue, i.e. remove all messages from the queue.

Yes

Use alternate fields for message correlation

These check-boxes select the fields which will be used for matching the response message with the original request.

Use Request Message Idif selected, the request JMSMessageID will be used, otherwise the request JMSCorrelationID will be used. In the latter case the correlation id must be specified in the request.Use Response Message Idif selected, the response JMSMessageID will be used, otherwise the response JMSCorrelationID will be used.

There are two frequently used JMS Correlation patterns:

JMS Correlation ID Pattern i.e. match request and response on their correlation Ids => deselect both checkboxes, and provide a correlation id. JMS Message ID Pattern i.e. match request message id with response correlation id => select "Use Request Message Id" only.

In both cases the JMS application is responsible for populating the correlation ID as necessary.

if the same queue is used to send and receive messages, then the response message will be the same as the request message. In which case, either provide a correlation id and clear both checkboxes; or select both checkboxes to use the message Id for correlation. This can be useful for checking raw JMS throughput.

Yes

Timeout

The timeout in milliseconds for the reply-messages. If a reply has not been received within the specified time, the specific testcase fails and the specific reply message received after the timeout is discarded. Default value is 2000 ms. 0 means no timeout.

Yes

Expiration

The expiration time [in milliseconds] of the message before it becomes obsolete. If you do not specify an expiration time, the default value is 0 [never expires].

Priority

The priority level of the message. There are ten priority levels from 0 [lowest] to 9 [highest]. If you do not specify a priority level, the default level is 4.

Use non-persistent delivery mode?

Whether to set DeliveryMode.NON_PERSISTENT.

Yes

Content

The content of the message.

JMS Properties

Initial Context Factory

The Initial Context Factory is the factory to be used to look up the JMS Resources.

JNDI properties

The JNDI Properties are the specific properties for the underlying JNDI implementation.

Provider URL

The URL for the JMS provider.

JUnit Request

The current implementation supports standard JUnit convention and extensions. It also includes extensions like oneTimeSetUp and oneTimeTearDown. The sampler works like the with some differences.

rather than use JMeter's test interface, it scans the jar files for classes extending JUnit's TestCase class. That includes any class or subclass.
JUnit test jar files should be placed in jmeter/lib/junit instead of /lib directory. You can also use the "user.classpath" property to specify where to look for TestCase classes.
JUnit sampler does not use name/value pairs for configuration like the . The sampler assumes setUp and tearDown will configure the test correctly.
The sampler measures the elapsed time only for the test method and does not include setUp and tearDown.
Each time the test method is called, JMeter will pass the result to the listeners.
Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since JMeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the same way Maven does it.
The sampler reports unexpected exceptions as errors. There are some important differences between standard JUnit test runners and JMeter's implementation. Rather than make a new instance of the class for each test, JMeter creates 1 instance per sampler and reuses it. This can be changed with checkbox "Create a new instance per sample".

The current implementation of the sampler will try to create an instance using the string constructor first. If the test class does not declare a string constructor, the sampler will look for an empty constructor. Example below:

JUnit Constructors

Empty Constructor:

https.default.protocol=SSLv3

String Constructor:

https.default.protocol=SSLv3

By default, JMeter will provide some default values for the success/failure code and message. Users should define a set of unique success and failure codes and use them uniformly across all tests.

General Guidelines

If you use setUp and tearDown, make sure the methods are declared public. If you do not, the test may not run properly. Here are some general guidelines for writing JUnit tests so they work well with JMeter. Since JMeter runs multi-threaded, it is important to keep certain things in mind.

Write the setUp and tearDown methods so they are thread safe. This generally means avoid using static members.
Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a discrete operation, it makes it easier to combine test methods to create new test plans.
Avoid making test methods depend on each other. Since JMeter allows arbitrary sequencing of test methods, the runtime behavior is different than the default JUnit behavior.
If a test method is configurable, be careful about where the properties are stored. Reading the properties from the Jar file is recommended.
Each sampler creates an instance of the test class, so write your test so the setup happens in oneTimeSetUp and oneTimeTearDown.

Screenshot of Control-Panel of JUnit Request

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

Search for JUnit4 annotations

Select this to search for JUnit4 tests [@Test annotations]

Yes

Package filter

Comma separated list of packages to show. Example, org.apache.jmeter,junit.framework.

Class name

Fully qualified name of the JUnit test class.

Yes

Constructor string

String pass to the string constructor. If a string is set, the sampler will use the string constructor instead of the empty constructor.

Test method

The method to test.

Yes

Success message

A descriptive message indicating what success means.

Success code

An unique code indicating the test was successful.

Failure message

A descriptive message indicating what failure means.

Failure code

An unique code indicating the test failed.

Error message

A description for errors.

Error code

Some code for errors. Does not need to be unique.

Do not call setUp and tearDown

Set the sampler not to call setUp and tearDown. By default, setUp and tearDown should be called. Not calling those methods could affect the test and make it inaccurate. This option should only be used with calling oneTimeSetUp and oneTimeTearDown. If the selected method is oneTimeSetUp or oneTimeTearDown, this option should be checked.

Yes

Append assertion errors

Whether or not to append assertion errors to the response message.

Yes

Append runtime exceptions

Whether or not to append runtime exceptions to the response message. Only applies if "Append assertion errors" is not selected.

Yes

Create a new Instance per sample

Whether or not to create a new JUnit instance for each sample. Defaults to false, meaning JUnit TestCase is created one and reused.

Yes

The following JUnit4 annotations are recognised:

@Testused to find test methods and classes. The "expected" and "timeout" attributes are supported.@Beforetreated the same as setUp[] in JUnit3@Aftertreated the same as tearDown[] in JUnit3@BeforeClass, @AfterClasstreated as test methods so they can be run independently as required

Note that JMeter currently runs the test methods directly, rather than leaving it to JUnit. This is to allow the setUp/tearDown methods to be excluded from the sample time. As a consequence, the sampler time excludes the time taken to call setUp/tearDown methods and their annotation based alternatives.

Mail Reader Sampler

The Mail Reader Sampler can read [and optionally delete] mail messages using POP3[S] or IMAP[S] protocols.

Screenshot of Control-Panel of Mail Reader Sampler

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

Server Type

The protocol used by the provider: e.g. pop3, pop3s, imap, imaps. or another string representing the server protocol. For example file for use with the read-only mail file provider. The actual provider names for POP3 and IMAP are pop3 and imap

Yes

Server

Hostname or IP address of the server. See below for use with file protocol.

Yes

Port

Port to be used to connect to the server [optional]

Password

User login password [N.B. this is stored unencrypted in the test plan]

Folder

The IMAP[S] folder to use. See below for use with file protocol.

Yes, if using IMAP[S]

Number of messages to retrieve

Set this to retrieve all or some messages

Yes

Fetch headers only

If selected, only the message headers will be retrieved.

Yes

Delete messages from the server

If set, messages will be deleted after retrieval

Yes

Store the message using MIME

Whether to store the message as MIME. If so, then the entire raw message is stored in the Response Data; the headers are not stored as they are available in the data. If not, the message headers are stored as Response Headers. A few headers are stored [Date, To, From, Subject] in the body.

Yes

Use no security features

Indicates that the connection to the server does not use any security protocol.

Use SSL

Indicates that the connection to the server must use the SSL protocol.

Use StartTLS

Indicates that the connection to the server should attempt to start the TLS protocol.

Enforce StartTLS

If the server does not start the TLS protocol the connection will be terminated.

Trust All Certificates

When selected it will accept all certificates independent of the CA.

Use local truststore

When selected it will only accept certificates that are locally trusted.

Local truststore

Path to file containing the trusted certificates. Relative paths are resolved against the current directory. Failing that, against the directory containing the test script [JMX file].

You can pass mail related environment properties by adding to user.properties any of the properties described here.

Messages are stored as subsamples of the main sampler. Multipart message parts are stored as subsamples of the message.

Special handling for "file" protocol: The file JavaMail provider can be used to read raw messages from files. The server field is used to specify the path to the parent of the folder. Individual message files should be stored with the name n.msg, where n is the message number. Alternatively, the server field can be the name of a file which contains a single message. The current implementation is quite basic, and is mainly intended for debugging purposes.

Flow Control Action [was: Test Action ]

The Flow Control Action sampler is a sampler that is intended for use in a conditional controller. Rather than generate a sample, the test element either pauses or stops the selected target.

This sampler can also be useful in conjunction with the Transaction Controller, as it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child.

The "Stop" action stops the thread or test after completing any samples that are in progress. The "Stop Now" action stops the test without waiting for samples to complete; it will interrupt any active samples. If some threads fail to stop within the 5 second time-limit, a message will be displayed in GUI mode. You can try using the Stop command to see if this will stop the threads, but if not, you should exit JMeter. In CLI mode, JMeter will exit if some threads fail to stop within the 5 second time limit.

The time to wait can be changed using the JMeter property jmeterengine.threadstop.wait. The time is given in milliseconds.

Screenshot of Control-Panel of Flow Control Action

Parameters

Attribute

Description

Required

Name

Descriptive name for this element that is shown in the tree.

Target

Current Thread / All Threads [ignored for Pause and Go to next loop iteration]

Yes

Action

Pause / Stop / Stop Now / Go to next loop iteration

Yes

Duration

How long to pause for [milliseconds]

Yes, if Pause is selected

SMTP Sampler

The SMTP Sampler can send mail messages using SMTP/SMTPS protocol. It is possible to set security protocols for the connection [SSL and TLS], as well as user authentication. If a security protocol is used a verification on the server certificate will occur. Two alternatives to handle this verification are available:

Trust all certificatesThis will ignore certificate chain verificationUse a local truststoreWith this option the certificate chain will be validated against the local truststore file.

Screenshot of Control-Panel of SMTP Sampler

Parameters

Attribute

Description

Required

Server

Hostname or IP address of the server. See below for use with file protocol.

Yes

Port

Port to be used to connect to the server. Defaults are: SMTP=25, SSL=465, StartTLS=587

Connection timeout

Connection timeout value in milliseconds [socket level]. Default is infinite timeout.

Read timeout

Read timeout value in milliseconds [socket level]. Default is infinite timeout.

Address From

The from address that will appear in the e-mail

Yes

Address To

The destination e-mail address [multiple values separated by ";"]

Yes, unless CC or BCC is specified

Address To CC

Carbon copy destinations e-mail address [multiple values separated by ";"]

Address To BCC

Blind carbon copy destinations e-mail address [multiple values separated by ";"]

Address Reply-To

Alternate Reply-To address [multiple values separated by ";"]

Use Auth

Indicates if the SMTP server requires user authentication

Password

User login password [N.B. this is stored unencrypted in the test plan]

Use no security features

Indicates that the connection to the SMTP server does not use any security protocol.

Use SSL

Indicates that the connection to the SMTP server must use the SSL protocol.

Use StartTLS

Indicates that the connection to the SMTP server should attempt to start the TLS protocol.

Enforce StartTLS

If the server does not start the TLS protocol the connection will be terminated.

Trust All Certificates

When selected it will accept all certificates independent of the CA.

Use local truststore

When selected it will only accept certificates that are locally trusted.

Local truststore

Path to file containing the trusted certificates. Relative paths are resolved against the current directory. Failing that, against the directory containing the test script [JMX file].

Override System SSL/TLS Protocols

Specify a custom SSL/TLS protocol as space separated list to use on handshake example TLSv1 TLSv1.1 TLSv1.2. Defaults to all supported protocols.

Subject

The e-mail message subject.

Suppress Subject Header

If selected, the "Subject:" header is omitted from the mail that is sent. This is different from sending an empty "Subject:" header, though some e-mail clients may display it identically.

Include timestamp in subject

Includes the System.currentTimemillis[] in the subject line.

Add Header

Additional headers can be defined using this button.

Message

The message body.

Send plain body [i.e. not multipart/mixed]

If selected, then send the body as a plain message, i.e. not multipart/mixed, if possible. If the message body is empty and there is a single file, then send the file contents as the message body.

Note: If the message body is not empty, and there is at least one attached file, then the body is sent as multipart/mixed.

Attach files

Files to be attached to the message.

Send .eml

If set, the .eml file will be sent instead of the entries in the Subject, Message, and Attach file[s] fields

Calculate message size

Calculates the message size and stores it in the sample result.

Enable debug logging?

If set, then the "mail.debug" property is set to "true"

OS Process Sampler

The OS Process Sampler is a sampler that can be used to execute commands on the local machine. It should allow execution of any command that can be run from the command line. Validation of the return code can be enabled, and the expected return code can be specified.

Note that OS shells generally provide command-line parsing. This varies between OSes, but generally the shell will split parameters on white-space. Some shells expand wild-card file names; some don't. The quoting mechanism also varies between OSes. The sampler deliberately does not do any parsing or quote handling. The command and its parameters must be provided in the form expected by the executable. This means that the sampler settings will not be portable between OSes.

Many OSes have some built-in commands which are not provided as separate executables. For example the Windows DIR command is part of the command interpreter [CMD.EXE]. These built-ins cannot be run as independent programs, but have to be provided as arguments to the appropriate command interpreter.

For example, the Windows command-line: DIR C:\TEMP needs to be specified as follows:

Command:CMDParam 1:/CParam 2:DIRParam 3:C:\TEMP

Screenshot of Control-Panel of OS Process Sampler

Parameters

Attribute

Description

Required

Command

The program name to execute.

Yes

Working directory

Directory from which command will be executed, defaults to folder referenced by "user.dir" System property

Command Parameters

Parameters passed to the program name.

Environment Parameters

Key/Value pairs added to environment when running command.

Standard input [stdin]

Name of file from which input is to be taken [STDIN].

Standard output [stdout

Name of output file for standard output [STDOUT]. If omitted, output is captured and returned as the response data.

Standard error [stderr]

Name of output file for standard error [STDERR]. If omitted, output is captured and returned as the response data.

Check Return Code

If checked, sampler will compare return code with Expected Return Code.

Expected Return Code

Expected return code for System Call, required if "Check Return Code" is checked. Note 500 is used as an error indicator in JMeter so you should not use it.

Timeout

Timeout for command in milliseconds, defaults to 0, which means no timeout. If the timeout expires before the command finishes, JMeter will attempt to kill the OS process.

MongoDB Script [DEPRECATED]

This sampler lets you send a Request to a MongoDB.

Before using this you need to set up a Configuration element

This Element currently uses com.mongodb.DB

eval which takes a global write lock causing a performance impact on the database, see db.eval[]. So it is better to avoid using this element for load testing and use JSR223+Groovy scripting using MongoDBHolder instead. MongoDB Script is more suitable for functional testing or test setup [setup/teardown threads]

Screenshot of Control-Panel of MongoDB Script [DEPRECATED]

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

MongoDB Source

Name of the JMeter variable that the MongoDB connection is bound to. This must agree with the 'MongoDB Source' field of a MongoDB Source Config.

Yes

Database Name

Database Name, will be used in your script

Yes

Script

Mongo script as it would be used in MongoDB shell

Yes

Ensure Variable Name is unique across Test Plan.

Bolt Request

This sampler allows you to run Cypher queries through the Bolt protocol.

Before using this you need to set up a

Every request uses a connection acquired from the pool and returns it to the pool when the sampler completes. The connection pool size defaults to 100 and is configurable.

The measured response time corresponds to the "full" query execution, including both the time to execute the cypher query AND the time to consume the results sent back by the database.

Screenshot of Control-Panel of Bolt Request

Parameters

Attribute

Description

Required

Name

Descriptive name for this sampler that is shown in the tree.

Comments

Free text for additional details.

Cypher statement

The query to execute.

Yes

Params

The parameter values, JSON formatted.

Record Query Results

Whether to add or not query result data to the sampler response [default false]. Note that activating this has a memory overhead, use it wisely.

Access Mode

Whether to access the database in WRITE or READ mode. Use WRITE for a standalone Neo4j instance. For a Neo4j cluster, select mode depending on whether the query writes to the database. That setting will allow correct routing to the cluster leader, followers or read replicas.

Yes

Database

The database to run the query against. Required for Neo4j 4.0+, unless querying the default database. Must be undefined for Neo4j 3.5.

Transaction timeout

Timeout for the transaction.

It is strongly advised to use query parameters, allowing the database to cache and reuse execution plans.

18.2 Logic Controllers

Logic Controllers determine the order in which Samplers are processed.

Simple Controller

The Simple Logic Controller lets you organize your Samplers and other Logic Controllers. Unlike other Logic Controllers, this controller provides no functionality beyond that of a storage device.

Screenshot of Control-Panel of Simple Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Using the Simple Controller

Download this example [see Figure 6]. In this example, we created a Test Plan that sends two Ant HTTP requests and two Log4J HTTP requests. We grouped the Ant and Log4J requests by placing them inside Simple Logic Controllers. Remember, the Simple Logic Controller has no effect on how JMeter processes the controller[s] you add to it. So, in this example, JMeter sends the requests in the following order: Ant Home Page, Ant News Page, Log4J Home Page, Log4J History Page.

Note, the File Reporter is configured to store the results in a file named "simple-test.dat" in the current directory.

Figure 6 Simple Controller Example

Loop Controller

If you add Generative or Logic Controllers to a Loop Controller, JMeter will loop through them a certain number of times, in addition to the loop value you specified for the Thread Group. For example, if you add one HTTP Request to a Loop Controller with a loop count of two, and configure the Thread Group loop count to three, JMeter will send a total of 2 * 3 = 6 HTTP Requests.

JMeter will expose the looping index as a variable named __jm____idx. So for example, if your Loop Controller is named LC, then you can access the looping index through ${__jm__LC__idx}. Index starts at 0

Screenshot of Control-Panel of Loop Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Loop Count

The number of times the subelements of this controller will be iterated each time through a test run.

The value -1 is equivalent to checking the Forever toggle.

Special Case: The Loop Controller embedded in the element behaves slightly different. Unless set to forever, it stops the test after the given number of iterations have been done.

When using a function in this field, be aware it may be evaluated multiple times. Example using will evaluate it to a different value for each child samplers of Loop Controller and result into unwanted behaviour.

Yes, unless "Forever" is checked

Looping Example

Download this example [see Figure 4]. In this example, we created a Test Plan that sends a particular HTTP Request only once and sends another HTTP Request five times.

Figure 4 - Loop Controller Example

We configured the Thread Group for a single thread and a loop count value of one. Instead of letting the Thread Group control the looping, we used a Loop Controller. You can see that we added one HTTP Request to the Thread Group and another HTTP Request to a Loop Controller. We configured the Loop Controller with a loop count value of five.

JMeter will send the requests in the following order: Home Page, News Page, News Page, News Page, News Page, and News Page.

Note, the File Reporter is configured to store the results in a file named "loop-test.dat" in the current directory.

Once Only Controller

The Once Only Logic Controller tells JMeter to process the controller[s] inside it only once per Thread, and pass over any requests under it during further iterations through the test plan.

The Once Only Controller will now execute always during the first iteration of any looping parent controller. Thus, if the Once Only Controller is placed under a Loop Controller specified to loop 5 times, then the Once Only Controller will execute only on the first iteration through the Loop Controller [i.e. every 5 times].

Note this means the Once Only Controller will still behave as previously expected if put under a Thread Group [runs only once per test per Thread], but now the user has more flexibility in the use of the Once Only Controller.

For testing that requires a login, consider placing the login request in this controller since each thread only needs to login once to establish a session.

Screenshot of Control-Panel of Once Only Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Once Only Example

Download this example [see Figure 5]. In this example, we created a Test Plan that has two threads that send HTTP request. Each thread sends one request to the Home Page, followed by three requests to the Bug Page. Although we configured the Thread Group to iterate three times, each JMeter thread only sends one request to the Home Page because this request lives inside a Once Only Controller.

Figure 5. Once Only Controller Example

Each JMeter thread will send the requests in the following order: Home Page, Bug Page, Bug Page, Bug Page.

Note, the File Reporter is configured to store the results in a file named "loop-test.dat" in the current directory.

Interleave Controller

If you add Generative or Logic Controllers to an Interleave Controller, JMeter will alternate among each of the other controllers for each loop iteration.

Screenshot of Control-Panel of Interleave Controller

Parameters

Attribute

Description

Required

name

Descriptive name for this controller that is shown in the tree.

ignore sub-controller blocks

If checked, the interleave controller will treat sub-controllers like single request elements and only allow one request per controller at a time.

Interleave across threads

If checked, the interleave controller will alternate among each of its children controllers for each loop iteration but across all threads, for example in a configuration with 4 threads and 3 child controllers, on first iteration thread 1 will run first child, thread 2 second child, thread 3 third child, thread 4 first child, on next iteration each thread will run the following child controller

Simple Interleave Example

Download this example [see Figure 1]. In this example, we configured the Thread Group to have two threads and a loop count of five, for a total of ten requests per thread. See the table below for the sequence JMeter sends the HTTP Requests.

Figure 1 - Interleave Controller Example 1 Loop IterationEach JMeter Thread Sends These HTTP Requests 1News Page 1Log Page 2FAQ Page 2Log Page 3Gump Page 3Log Page 4Because there are no more requests in the controller,

JMeter starts over and sends the first HTTP Request, which is the News Page.

4Log Page 5FAQ Page 5Log Page

Useful Interleave Example

Download another example [see Figure 2]. In this example, we configured the Thread Group to have a single thread and a loop count of eight. Notice that the Test Plan has an outer Interleave Controller with two Interleave Controllers inside of it.

Figure 2 - Interleave Controller Example 2

The outer Interleave Controller alternates between the two inner ones. Then, each inner Interleave Controller alternates between each of the HTTP Requests. Each JMeter thread will send the requests in the following order: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved.

Note, the File Reporter is configured to store the results in a file named "interleave-test2.dat" in the current directory.

Figure 3 - Interleave Controller Example 3

If the two interleave controllers under the main interleave controller were instead simple controllers, then the order would be: Home Page, CVS Page, Interleaved, Bug Page, FAQ Page, Interleaved.

However, if "ignore sub-controller blocks" was checked on the main interleave controller, then the order would be: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved.

Random Controller

The Random Logic Controller acts similarly to the Interleave Controller, except that instead of going in order through its sub-controllers and samplers, it picks one at random at each pass.

Interactions between multiple controllers can yield complex behavior. This is particularly true of the Random Controller. Experiment before you assume what results any given interaction will give

Screenshot of Control-Panel of Random Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

ignore sub-controller blocks

If checked, the interleave controller will treat sub-controllers like single request elements and only allow one request per controller at a time.

Random Order Controller

The Random Order Controller is much like a Simple Controller in that it will execute each child element at most once, but the order of execution of the nodes will be random.

Screenshot of Control-Panel of Random Order Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Throughput Controller

The Throughput Controller allows the user to control how often it is executed. There are two modes:

percent execution
total executions Percent executionscauses the controller to execute a certain percentage of the iterations through the test plan.Total executionscauses the controller to stop executing after a certain number of executions have occurred.

Like the Once Only Controller, this setting is reset when a parent Loop Controller restarts.

This controller is badly named, as it does not control throughput. Please refer to the for an element that can be used to adjust the throughput.

Screenshot of Control-Panel of Throughput Controller

The Throughput Controller can yield very complex behavior when combined with other controllers - in particular with interleave or random controllers as parents [also very useful].

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Execution Style

Whether the controller will run in percent executions or total executions mode.

Yes

Throughput

A number. For percent execution mode, a number from 0-100 that indicates the percentage of times the controller will execute. "50" means the controller will execute during half the iterations through the test plan. For total execution mode, the number indicates the total number of times the controller will execute.

Yes

Per User

If checked, per user will cause the controller to calculate whether it should execute on a per user [per thread] basis. If unchecked, then the calculation will be global for all users. For example, if using total execution mode, and uncheck "per user", then the number given for throughput will be the total number of executions made. If "per user" is checked, then the total number of executions would be the number of users times the number given for throughput.

Runtime Controller

The Runtime Controller controls how long its children will run. Controller will run its children until configured Runtime[s] is exceeded.

Screenshot of Control-Panel of Runtime Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree, and used to name the transaction.

Yes

Runtime [seconds]

Desired runtime in seconds. 0 means no run.

Yes

If Controller

The If Controller allows the user to control whether the test elements below it [its children] are run or not.

By default, the condition is evaluated only once on initial entry, but you have the option to have it evaluated for every runnable element contained in the controller.

The best option [default one] is to check Interpret Condition as Variable Expression?, then in the condition field you have 2 options:

Option 1: Use a variable that contains true or false If you want to test if last sample was successful, you can use ${JMeterThread.last_sample_ok}
If Controller using Variable
Option 2: Use a function [${__jexl3[]} is advised] to evaluate an expression that must return true or false
If Controller using expression

For example, previously one could use the condition:${__jexl3[${VAR} == 23]} and this would be evaluated as true/false, the result would then be passed to JavaScript which would then return true/false. If the Variable Expression option is selected, then the expression is evaluated and compared with "true", without needing to use JavaScript.

To test if a variable is undefined [or null] do the following, suppose var is named myVar, expression will be:

https.default.protocol=SSLv3

Or use:

"Redirect requested but followRedirects is disabled"

to test if a variable is defined and is not null.

If you uncheck Interpret Condition as Variable Expression?, If Controller will internally use javascript to evaluate the condition which has a performance penalty that can be very big and make your test less scalable.

If Controller using javascript

Screenshot of Control-Panel of If Controller

Parameters

Attribute

Description

Required

Name

Descriptive name for this controller that is shown in the tree.

Condition [default JavaScript]

By default the condition is interpreted as JavaScript code that returns "true" or "false", but this can be overridden [see below]

Yes

Interpret Condition as Variable Expression?

If this is selected, then the condition must be an expression that evaluates to "true" [case is ignored]. For example, ${FOUND} or ${__jexl3[${VAR} > 100]}. Unlike the JavaScript case, the condition is only checked to see if it matches "true" [case is ignored].

Checking this and using or function in Condition is advised for performances

Yes

Evaluate for all children

Should condition be evaluated for all children? If not checked, then the condition is only evaluated on entry.

Yes

Examples [JavaScript]

${COUNT} < 10
"${VAR}" == "abcd"

If there is an error interpreting the code, the condition is assumed to be false, and a message is logged in jmeter.log.

Note it is advised to avoid using JavaScript mode for performance.

When using take care to not use variable replacement in the string, otherwise if using a variable that changes the script cannot be cached. Instead get the variable using: vars.get["myVar"]. See the Groovy examples below.

Examples [Variable Expression]

${__groovy[vars.get["myVar"] != "Invalid" ]} [Groovy check myVar is not equal to Invalid]
${__groovy[vars.get["myInt"].toInteger[] 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
0
which would define the variable "HOST" to have the value of the JMeter property "host", defaulting to "localhost" if not defined.
For defining variables during a test run, see . UDVs are processed in the order they appear in the Plan, from top to bottom.
For simplicity, it is suggested that UDVs are placed only at the start of a Thread Group [or perhaps under the Test Plan itself].
Once the Test Plan and all UDVs have been processed, the resulting set of variables is copied to each thread to provide the initial set of variables.
If a runtime element such as a User Parameters Pre-Processor or Regular Expression Extractor defines a variable with the same name as one of the UDV variables, then this will replace the initial value, and all other test elements in the thread will see the updated value.
Screenshot of Control-Panel of User Defined Variables
If you have more than one Thread Group, make sure you use different names for different values, as UDVs are shared between Thread Groups. Also, the variables are not available for use until after the element has been processed, so you cannot reference variables that are defined in the same element. You can reference variables defined in earlier UDVs or on the Test Plan.
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
User Defined Variables
Variable name/value pairs. The string under the "Name" column is what you'll need to place inside the brackets in ${…} constructs to use the variables later on. The whole ${…} will then be replaced by the string in the "Value" column.
Random Variable
The Random Variable Config Element is used to generate random numeric strings and store them in variable for use later. It's simpler than using together with the function.
The output variable is constructed by using the random number generator, and then the resulting number is formatted using the format string. The number is calculated using the formula minimum+Random.nextInt[maximum-minimum+1].Random.nextInt[] requires a positive integer. This means that maximum-minimum - i.e. the range - must be less than 2147483647, however the minimum and maximum values can be any long values so long as the range is OK.
As the random value is evaluated at the start of each iteration, it is probably not a good idea to use a variable other than a property as a value for the minimum or maximum. It would be zero on the first iteration.
Screenshot of Control-Panel of Random Variable
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Yes
Variable Name
The name of the variable in which to store the random string.
Yes
Format String
The java.text.DecimalFormat format string to be used. For example "000" which will generate numbers with at least 3 digits, or "USER_000" which will generate output of the form USER_nnn. If not specified, the default is to generate the number using Long.toString[]
No
Minimum Value
The minimum value [long] of the generated random number.
Yes
Maximum Value
The maximum value [long] of the generated random number.
Yes
Random Seed
The seed for the random number generator. If you use the same seed value with Per Thread set to true, you will get the same value for each Thread as per Random class. If no seed is set, Default constructor of Random will be used.
No
Per Thread[User]?
If False, the generator is shared between all threads in the thread group. If True, then each thread has its own random generator.
Yes
Counter
Allows the user to create a counter that can be referenced anywhere in the Thread Group. The counter config lets the user configure a starting point, a maximum, and the increment. The counter will loop from the start to the max, and then start over with the start, continuing on like that until the test is ended.
The counter uses a long to store the value, so the range is from -2^63 to 2^63-1.
Screenshot of Control-Panel of Counter
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Starting value
The starting value for the counter. The counter will equal this value during the first iteration [defaults to 0].
No
Increment
How much to increment the counter by after each iteration [defaults to 0, meaning no increment].
Yes
Maximum value
If the counter exceeds the maximum, then it is reset to the Starting value. Default is Long.MAX_VALUE
No
Format
Optional format, e.g. 000 will format as 001, 002, etc. This is passed to DecimalFormat, so any valid formats can be used. If there is a problem interpreting the format, then it is ignored. [The default format is generated using Long.toString[]]
No
Exported Variable Name
This will be the variable name under which the counter value is available. If you name it counterA, you can then access it using ${counterA} as explained in user-defined values [By default, it creates an empty string variable that can be accessed using ${} but this is highly discouraged]
No
Track Counter Independently for each User
In other words, is this a global counter, or does each user get their own counter? If unchecked, the counter is global [i.e., user
1 will get value "1", and user

2 will get value "2" on the first iteration]. If checked, each user has an independent counter.
No
Reset counter on each Thread Group Iteration
This option is only available when counter is tracked per User, if checked, counter will be reset to Start value on each Thread Group iteration. This can be useful when Counter is inside a Loop Controller.
No
Simple Config Element
The Simple Config Element lets you add or override arbitrary values in samplers. You can choose the name of the value and the value itself. Although some adventurous users might find a use for this element, it's here primarily for developers as a basic GUI that they can use while developing new JMeter components.
Screenshot of Control-Panel of Simple Config Element
Parameters
Attribute
Description
Required
Name

Descriptive name for this element that is shown in the tree.
Yes
Parameter Name
The name of each parameter. These values are internal to JMeter's workings and are not generally documented. Only those familiar with the code will know these values.
Yes
Parameter Value
The value to apply to that parameter.
Yes
MongoDB Source Config [DEPRECATED]
Creates a MongoDB connection [used by Sampler] from the supplied Connection settings. Each thread gets its own connection. The connection configuration name is used by the JDBC Sampler to select the appropriate connection.
You can then access com.mongodb.DB object in Beanshell or JSR223 Test Elements through the element MongoDBHolder using this code
Define characters per second > 0 to emulate slow connections

httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
1
Screenshot of Control-Panel of MongoDB Source Config [DEPRECATED]
Parameters
Attribute
Description
Required
Name
Descriptive name for the connection configuration that is shown in the tree.
No
Server Address List
Mongo DB Servers
Yes
MongoDB Source
The name of the variable the connection is tied to.
Each name must be different. If there are two configuration elements using the same name, only one will be saved.
Yes
Keep Trying
If true, the driver will keep trying to connect to the same server in case that the socket cannot be established. There is maximum amount of time to keep retrying, which is 15s by default. This can be useful to avoid some exceptions being thrown when a server is down temporarily by blocking the operations. It can also be useful to smooth the transition to a new primary node [so that a new primary node is elected within the retry time].
Note that when using this flag
- for a replica set, the driver will try to connect to the old primary node for that time, instead of failing over to the new one right away
- this does not prevent exception from being thrown in read/write operations on the socket, which must be handled by application.
Even if this flag is false, the driver already has mechanisms to automatically recreate broken connections and retry the read operations.
Default is false.
No
Maximum connections per host
No
Connection timeout
The connection timeout in milliseconds. It is used solely when establishing a new connection Socket.connect[java.net.SocketAddress, int] Default is 0 and means no timeout.
No
Maximum retry time
The maximum amount of time in milliseconds to spend retrying to open connection to the same server. Default is 0, which means to use the default 15s if autoConnectRetry is on.
No
Maximum wait time
The maximum wait time in milliseconds that a thread may wait for a connection to become available. Default is 120,000.
No
Socket timeout
The socket timeout in milliseconds It is used for I/O socket read and write operations Socket.setSoTimeout[int] Default is 0 and means no timeout.
No
Socket keep alive
This flag controls the socket keep alive feature that keeps a connection alive through firewalls Socket.setKeepAlive[boolean] Default is false.
No
ThreadsAllowedToBlockForConnectionMultiplier
This multiplier, multiplied with the connectionsPerHost setting, gives the maximum number of threads that may be waiting for a connection to become available from the pool. All further threads will get an exception right away. For example if connectionsPerHost is 10 and threadsAllowedToBlockForConnectionMultiplier is 5, then up to 50 threads can wait for a connection. Default is 5.
No
Write Concern: Safe
If true the driver will use a WriteConcern of WriteConcern.SAFE for all operations. If w, wtimeout, fsync or j are specified, this setting is ignored. Default is false.
No
Write Concern: Fsync
The fsync value of the global WriteConcern. Default is false.
No
Write Concern: Wait for Journal
The j value of the global WriteConcern. Default is false.
No
Write Concern: Wait for servers
The w value of the global WriteConcern. Default is 0.
No
Write Concern: Wait timeout
The wtimeout value of the global WriteConcern. Default is 0.
No
Write Concern: Continue on error
If batch inserts should continue after the first error
No
Bolt Connection Configuration
Creates a Bolt connection pool [used by Sampler] from the supplied Connection settings.
Screenshot of Control-Panel of Bolt Connection Configuration
Parameters
Attribute
Description
Required
Name
Descriptive name for this sampler that is shown in the tree.
No
Comments
Free text for additional details.
No
Bolt URI
The database URI.
Yes
Username
User account.
No
Password
User credentials.
No
Connection Pool Max Size
Max size of the Neo4j driver Bolt connection pool. Raise the value if running large number of concurrent threads, so that JMeter threads are not blocked waiting for a connection to be released to the pool.
Yes
18.5 Assertions
Assertions are used to perform additional checks on samplers, and are processed after every sampler in the same scope. To ensure that an Assertion is applied only to a particular sampler, add it as a child of the sampler.
Note: Unless documented otherwise, Assertions are not applied to sub-samples [child samples] - only to the parent sample. In the case of JSR223 and BeanShell Assertions, the script can retrieve sub-samples using the methodprev.getSubResults[] which returns an array of SampleResults. The array will be empty if there are none.
Assertions can be applied to either the main sample, the sub-samples or both. The default is to apply the assertion to the main sample only. If the Assertion supports this option, then there will be an entry on the GUI which looks like the following:
Assertion Scope
or the following
Assertion Scope
If a sub-sampler fails and the main sample is successful, then the main sample will be set to failed status and an Assertion Result will be added. If the JMeter variable option is used, it is assumed to relate to the main sample, and any failure will be applied to the main sample only.
The variable JMeterThread.last_sample_ok is updated to "true" or "false" after all assertions for a sampler have been run.
Response Assertion
The response assertion control panel lets you add pattern strings to be compared against various fields of the request or response. The pattern strings are:
- Contains, Matches: Perl5-style regular expressions
- Equals, Substring: plain text, case-sensitive
A summary of the pattern matching characters can be found at ORO Perl5 regular expressions.
You can also choose whether the strings will be expected to match the entire response, or if the response is only expected to contain the pattern. You can attach multiple assertions to any controller for additional flexibility.
Note that the pattern string should not include the enclosing delimiters, i.e. use Price: \d+ not /Price: \d+/.
By default, the pattern is in multi-line mode, which means that the "." meta-character does not match newline. In multi-line mode, "^" and "$" match the start or end of any line anywhere within the string - not just the start and end of the entire string. Note that \s does match new-line. Case is also significant. To override these settings, one can use the extended regular expression syntax. For example:
[?i]ignore case[?s]treat target as single line, i.e. "." matches new-line[?is]both the above
These can be used anywhere within the expression and remain in effect until overridden. E.g.
[?i]apple[?-i] Piematches "ApPLe Pie", but not "ApPLe pIe"[?s]Apple.+?Piematches Apple followed by Pie, which may be on a subsequent line.Apple[?s].+?Piesame as above, but it's probably clearer to use the [?s] at the start.
Screenshot of Control-Panel of Response Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - assertion is to be applied to the contents of the named variable
Yes
Field to Test
Instructs JMeter which field of the Request or Response to test.
- Text Response - the response text from the server, i.e. the body, excluding any HTTP headers.
- Request data - the request text sent to the server, i.e. the body, excluding any HTTP headers.
- Response Code - e.g. 200
- Response Message - e.g. OK
- Response Headers, including Set-Cookie headers [if any]
- Request Headers
- URL sampled
- Document [text] - the extract text from various type of documents via Apache Tika [see Document view section].
Yes
Ignore status
Instructs JMeter to set the status to success initially.
The overall success of the sample is determined by combining the result of the assertion with the existing Response status. When the Ignore Status checkbox is selected, the Response status is forced to successful before evaluating the Assertion.
HTTP Responses with statuses in the 4xx and 5xx ranges are normally regarded as unsuccessful. The "Ignore status" checkbox can be used to set the status successful before performing further checks.
Note that this will have the effect of clearing any previous assertion failures, so make sure that this is only set on the first assertion.
Yes
Pattern Matching Rules
Indicates how the text being tested is checked against the pattern.
- Contains - true if the text contains the regular expression pattern
- Matches - true if the whole text matches the regular expression pattern
- Equals - true if the whole text equals the pattern string [case-sensitive]
- Substring - true if the text contains the pattern string [case-sensitive]
Equals and Substring patterns are plain strings, not regular expressions.NOT may also be selected to invert the result of the check.OR Apply each assertion in OR combination [if 1 pattern to test matches, Assertion will be ok] instead of AND [All patterns must match so that Assertion is OK].
Yes
Patterns to Test
A list of patterns to be tested. Each pattern is tested separately. If a pattern fails, then further patterns are not checked. There is no difference between setting up one Assertion with multiple patterns and setting up multiple Assertions with one pattern each [assuming the other options are the same].
However, when the Ignore Status checkbox is selected, this has the effect of cancelling any previous assertion failures - so make sure that the Ignore Status checkbox is only used on the first Assertion.
Yes
Custom failure message
Lets you define the failure message that will replace the generated one
No
The pattern is a Perl5-style regular expression, but without the enclosing brackets.
Duration Assertion
The Duration Assertion tests that each response was received within a given amount of time. Any response that takes longer than the given number of milliseconds [specified by the user] is marked as a failed response.
Screenshot of Control-Panel of Duration Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Duration in Milliseconds
The maximum number of milliseconds each response is allowed before being marked as failed.
Yes
Size Assertion
The Size Assertion tests that each response contains the right number of bytes in it. You can specify that the size be equal to, greater than, less than, or not equal to a given number of bytes.
An empty response is treated as being 0 bytes rather than reported as an error.
Screenshot of Control-Panel of Size Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - assertion only applies to the main sample
- Sub-samples only - assertion only applies to the sub-samples
- Main sample and sub-samples - assertion applies to both.
- JMeter Variable Name to use - assertion is to be applied to the contents of the named variable
Yes
Size in bytes
The number of bytes to use in testing the size of the response [or value of the JMeter variable].
Yes
Type of Comparison
Whether to test that the response is equal to, greater than, less than, or not equal to, the number of bytes specified.
Yes
XML Assertion
The XML Assertion tests that the response data consists of a formally correct XML document. It does not validate the XML based on a DTD or schema or do any further validation.
Screenshot of Control-Panel of XML Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
BeanShell Assertion
The BeanShell Assertion allows the user to perform assertion checking using a BeanShell script.
For full details on using BeanShell, please see the BeanShell website.
Migration to +Groovy is highly recommended for performance, support of new Java features and limited maintenance of the BeanShell library.
Note that a different Interpreter is used for each independent occurrence of the assertion in each thread in a test script, but the same Interpreter is used for subsequent invocations. This means that variables persist across calls to the assertion.
All Assertions are called from the same thread as the sampler.
If the property "beanshell.assertion.init" is defined, it is passed to the Interpreter as the name of a sourced file. This can be used to define common methods and variables. There is a sample init file in the bin directory: BeanShellAssertion.bshrc
The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.
Screenshot of Control-Panel of BeanShell Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree. The name is stored in the script variable Label
Reset bsh.Interpreter before each call
If this option is selected, then the interpreter will be recreated for each sample. This may be necessary for some long running scripts. For further information, see .
Yes
Parameters
Parameters to pass to the BeanShell script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- bsh.args - String array containing parameters, split on white-space
No
Script file
A file containing the BeanShell script to run. This overrides the script. The file name is stored in the script variable FileName
No
Script
The BeanShell script to run. The return value is ignored.
Yes [unless script file is provided]
There's a sample script you can try.
Before invoking the script, some variables are set up in the BeanShell interpreter. These are strings unless otherwise noted:
- log - the Logger Object. [e.g.] log.warn["Message"[,Throwable]]
- SampleResult, prev - the SampleResult Object; read-write
- Response - the response Object; read-write
- Failure - boolean; read-write; used to set the Assertion status
- FailureMessage - String; read-write; used to set the Assertion message
- ResponseData - the response body [byte []]
- ResponseCode - e.g. 200
- ResponseMessage - e.g. OK
- ResponseHeaders - contains the HTTP headers
- RequestHeaders - contains the HTTP headers sent to the server
- SampleLabel
- SamplerData - data that was sent to the server
- ctx - JMeterContext
- vars - JMeterVariables - e.g.
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
2
- props - JMeterProperties [class java.util.Properties] - e.g. httpclient.reset_state_on_thread_group_iteration=true 6
The following methods of the Response object may be useful:
- setStopThread[boolean]
- setStopTest[boolean]
- String getSampleLabel[]
- setSampleLabel[String]
MD5Hex Assertion
The MD5Hex Assertion allows the user to check the MD5 hash of the response data.
Screenshot of Control-Panel of MD5Hex Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
MD5 sum
32 hex digits representing the MD5 hash [case not significant]
Yes
HTML Assertion
The HTML Assertion allows the user to check the HTML syntax of the response data using JTidy.
Screenshot of Control-Panel of HTML Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
doctype
omit, auto, strict or loose
Yes
Format
HTML, XHTML or XML
Yes
Errors only
Only take note of errors?
Yes
Error threshold
Number of errors allowed before classing the response as failed
Yes
Warning threshold
Number of warnings allowed before classing the response as failed
Yes
Filename
Name of file to which report is written
No
XPath Assertion
The XPath Assertion tests a document for well formedness, has the option of validating against a DTD, or putting the document through JTidy and testing for an XPath. If that XPath exists, the Assertion is true. Using "/" will match any well-formed document, and is the default XPath Expression. The assertion also supports boolean expressions, such as "count[//*error]=2". See //www.w3.org/TR/xpath for more information on XPath.
Some sample expressions:
- //title[text[]='Text to match'] - matches Text to match anywhere in the response
- /title[text[]='Text to match'] - matches Text to match at root level in the response
Screenshot of Control-Panel of XPath Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Use Tidy [tolerant parser]
Use Tidy, i.e. be tolerant of XML/HTML errors
Yes
Quiet
Sets the Tidy Quiet flag
If Tidy is selected
Report Errors
If a Tidy error occurs, then set the Assertion accordingly
If Tidy is selected
Show warnings
Sets the Tidy showWarnings option
If Tidy is selected
Use Namespaces
Should namespaces be honoured? [see note below on NAMESPACES]
If Tidy is not selected
Validate XML
Check the document against its schema.
If Tidy is not selected
Ignore Whitespace
Ignore Element Whitespace.
If Tidy is not selected
Fetch External DTDs
If selected, external DTDs are fetched.
If Tidy is not selected
XPath Assertion
XPath to match in the document.
Yes
Invert assertion[will fail if above conditions met]
True if a XPath expression is not matched or returns false
No
The non-tolerant parser can be quite slow, as it may need to download the DTD etc.
NAMESPACES As a work-round for namespace limitations of the Xalan XPath parser [implementation on which JMeter is based] you need to:
- provide a Properties file [if for example your file is named namespaces.properties] which contains mappings for the namespace prefixes:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
4
- reference this file in user.properties file using the property:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
5
XPath2 Assertion
The XPath2 Assertion tests a document for well formedness. Using "/" will match any well-formed document, and is the default XPath2 Expression. The assertion also supports boolean expressions, such as "count[//*error]=2".
Some sample expressions:
- //title[text[]='Text to match'] - matches Text to match anywhere in the response
- /title[text[]='Text to match'] - matches Text to match at root level in the response
Screenshot of Control-Panel of XPath2 Assertion
Parameters
Attribute
Description
Required
Namespaces aliases list
List of namespaces aliases you want to use to parse the document, one line per declaration. You must specify them as follow: prefix=namespace. This implementation makes it easier to use namespaces than with the old XPathExtractor version.
No
XPath2 Assertion
XPath to match in the document.
Yes
Invert assertion
Will fail if xpath expression returns true or matches, succeed otherwise
No
Namespace aliases list
List of namespace aliases prefix=full namespace [one per line]
No
XML Schema Assertion
The XML Schema Assertion allows the user to validate a response against an XML Schema.
Screenshot of Control-Panel of XML Schema Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
File Name
Specify XML Schema File Name
Yes
JSR223 Assertion
The JSR223 Assertion allows JSR223 script code to be used to check the status of the previous sample.
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Language
The JSR223 language to be used
Yes
Parameters
Parameters to pass to the script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- args - String array containing parameters, split on white-space
No
Script file
A file containing the script to run, if a relative file path is used, then it will be relative to directory referenced by "user.dir" System property
No
Script compilation caching
Unique String across Test Plan that JMeter will use to cache result of Script compilation if language used supports Compilable interface [Groovy is one of these, java, BeanShell and JavaScript are not]
See note in JSR223 Sampler Java System property if you're using Groovy without checking this option
No
Script
The script to run.
Yes [unless script file is provided]
The following variables are set up for use by the script:
- log - [Logger] - can be used to write to the log file
- Label - the String Label
- Filename - the script file name [if any]
- Parameters - the parameters [as a String]
- args - the parameters as a String array [split on whitespace]
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
6
- props - [JMeterProperties - class java.util.Properties] - e.g.
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
7
- SampleResult, prev - [SampleResult] - gives access to the previous SampleResult [if any]
- sampler - [Sampler] - gives access to the current sampler
- OUT - System.out - e.g. OUT.println["message"]
- AssertionResult - [AssertionResult] - the assertion result
The script can check various aspects of the SampleResult. If an error is detected, the script should use AssertionResult.setFailureMessage["message"] and AssertionResult.setFailure[true].
For further details of all the methods available on each of the above variables, please check the Javadoc
Compare Assertion
Compare Assertion must not be used during load test as it consumes a lot of resources [memory and CPU]. Use it only for either functional testing or during Test Plan debugging and Validation.
The Compare Assertion can be used to compare sample results within its scope. Either the contents or the elapsed time can be compared, and the contents can be filtered before comparison. The assertion comparisons can be seen in the .
Screenshot of Control-Panel of Compare Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Compare Content
Whether or not to compare the content [response data]
Yes
Compare Time
If the value is ≥0, then check if the response time difference is no greater than the value. I.e. if the value is 0, then the response times must be exactly equal.
Yes
Comparison Filters
Filters can be used to remove strings from the content comparison. For example, if the page has a time-stamp, it might be matched with: "Time: \d\d:\d\d:\d\d" and replaced with a dummy fixed time "Time: HH:MM:SS".
No
SMIME Assertion
The SMIME Assertion can be used to evaluate the sample results from the Mail Reader Sampler. This assertion verifies if the body of a mime message is signed or not. The signature can also be verified against a specific signer certificate. As this is a functionality that is not necessarily needed by most users, additional jars need to be downloaded and added to JMETER_HOME/lib:
- bcmail-xxx.jar [BouncyCastle SMIME/CMS]
- bcprov-xxx.jar [BouncyCastle Provider]
These need to be downloaded from BouncyCastle.
If using the , please ensure that you select "Store the message using MIME [raw]" otherwise the Assertion won't be able to process the message correctly.
Screenshot of Control-Panel of SMIME Assertion
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Verify Signature
If selected, the assertion will verify if it is a valid signature according to the parameters defined in the Signer Certificate box.
Yes
Message not signed
Whether or not to expect a signature in the message
Yes
Signer Certificate
"No Check" means that it will not perform signature verification. "Check values" is used to verify the signature against the inputs provided. And "Certificate file" will perform the verification against a specific certificate file.
Yes
Message Position
The Mail sampler can retrieve multiple messages in a single sample. Use this field to specify which message will be checked. Messages are numbered from 0, so 0 means the first message. Negative numbers count from the LAST message; -1 means LAST, -2 means penultimate etc.
Yes
JSON Assertion
This component allows you to perform validations of JSON documents. First, it will parse the JSON and fail if the data is not JSON. Second, it will search for specified path, using syntax from Jayway JsonPath 1.2.0. If the path is not found, it will fail. Third, if JSON path was found in the document, and validation against expected value was requested, it will perform validation. For the null value there is special checkbox in the GUI. Note that if the path will return array object, it will be iterated and if expected value is found, the assertion will succeed. To validate empty array use [] string. Also, if patch will return dictionary object, it will be converted to string before comparison.
When using you must assert the value due to the existing JSON library implementation, otherwise the assertion could always return successful. Since JMeter version 5.5 the assertion will fail, if an indefinite path is given, an empty list is extracted and no assertion value is set.
Screenshot of Control-Panel of JSON Assertion
Parameters
Attribute
Description
Required
Assert JSON Path exists
Path to JSON element for assert.
Yes
Additionally assert value
Select checkbox if you want make assert with some value
No
Match as regular expression
Select checkbox if you want use regular expression
No
Expected Value
Value for assert or regular expression for match
No
Expect null
Select checkbox if you expect null
No
Invert assertion [will fail if above conditions met]
Invert assertion [will fail if above conditions met]
No
JSON JMESPath Assertion
This component allows you to perform assertion on JSON documents content using JMESPath. First, it will parse the JSON and fail if the data is not JSON. Second, it will search for specified path, using JMESPath syntax. If the path is not found, it will fail. Third, if JMES path was found in the document, and validation against expected value was requested, it will perform this additional check. If you want to check for nullity, use the Expect null checkbox. Note that the path cannot be null as the expression JMESPath will not be compiled and an error will occur. Even if you expect an empty or null response, you must put a valid JMESPath expression.
Screenshot of Control-Panel of JSON JMESPath Assertion
Parameters
Attribute
Description
Required
Assert JMESPath exists
Check that JMESPath to JSON element exists
Yes
Additionally assert value
Select checkbox if you check the extracted JMESPath against an expected one
No
Match as regular expression
Select checkbox if you want to use a regular expression for matching
No
Expected Value
Value to use for exact matching or regular expression if Match as regular expression is checked
No
Expect null
Select checkbox if you expect the value to be null
No
Invert assertion [will fail if above conditions met]
Invert assertion [will fail if above conditions met]
No
18.6 Timers
Since version 3.1, a new feature [in Beta mode as of JMeter 3.1 and subject to changes] has been implemented which provides the following feature. You can apply a multiplication factor on the sleep delays computed by Random timer by setting property timer.factor=float number where float number is a decimal positive number. JMeter will multiply this factor by the computed sleep delay. This feature can be used by:
Note that timers are processed before each sampler in the scope in which they are found; if there are several timers in the same scope, all the timers will be processed before each sampler. Timers are only processed in conjunction with a sampler. A timer which is not in the same scope as a sampler will not be processed at all. To apply a timer to a single sampler, add the timer as a child element of the sampler. The timer will be applied before the sampler is executed. To apply a timer after a sampler, either add it to the next sampler, or add it as the child of a Sampler.
Constant Timer
If you want to have each thread pause for the same amount of time between requests, use this timer.
Screenshot of Control-Panel of Constant Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree.
No
Thread Delay
Number of milliseconds to pause.
Yes
Gaussian Random Timer
This timer pauses each thread request for a random amount of time, with most of the time intervals occurring near a particular value. The total delay is the sum of the Gaussian distributed value [with mean 0.0 and standard deviation 1.0] times the deviation value you specify, and the offset value. Another way to explain it, in Gaussian Random Timer, the variation around constant offset has a Gaussian curve distribution.
Screenshot of Control-Panel of Gaussian Random Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree
No
Deviation
Deviation in milliseconds.
Yes
Constant Delay Offset
Number of milliseconds to pause in addition to the random delay.
Yes
Uniform Random Timer
This timer pauses each thread request for a random amount of time, with each time interval having the same probability of occurring. The total delay is the sum of the random value and the offset value.
Screenshot of Control-Panel of Uniform Random Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree.
No
Random Delay Maximum
Maximum random number of milliseconds to pause.
Yes
Constant Delay Offset
Number of milliseconds to pause in addition to the random delay.
Yes
Constant Throughput Timer
This timer introduces variable pauses, calculated to keep the total throughput [in terms of samples per minute] as close as possible to a given figure. Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.
N.B. although the Timer is called the Constant Throughput timer, the throughput value does not need to be constant. It can be defined in terms of a variable or function call, and the value can be changed during a test. The value can be changed in various ways:
- using a counter variable
- using a __jexl3, __groovy function to provide a changing value
- using the remote BeanShell server to change a JMeter property
See Best Practices for further details.
Note that the throughput value should not be changed too often during a test - it will take a while for the new value to take effect.
Screenshot of Control-Panel of Constant Throughput Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree.
No
Target Throughput
Throughput we want the timer to try to generate.
Yes
Calculate Throughput based on
- 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 needed, based on when it last ran. In this 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.
Yes
The shared and non-shared algorithms both aim to generate the desired throughput, and will produce similar results. The shared algorithm should generate a more accurate overall transaction rate. The non-shared algorithm should generate a more even spread of transactions across threads.
Precise Throughput Timer
This timer introduces variable pauses, calculated to keep the total throughput [e.g. in terms of samples per minute] as close as possible to a given figure. The timer does not generate threads, so the resulting throughput will be lower if the server is not capable of handling it, or if other timers add too big delays, or if there's not enough threads, or time-consuming test elements prevent it.
Note: in many cases, Open Model Thread Group would be a better choice for generating the desired load profile
Note: if you alter timer configuration on the fly, then it might take time to adapt to the new settings. For instance, if the timer was initially configured for 1 request per hour, then it assigns incoming threads with 3600+sec pauses. Then, if the load configuration is altered to 1 per second, then the threads are not interrupted from their delays, and the threads keep waiting.
Although the Timer is called Precise Throughput Timer, it does not aim to produce precisely the same number of samples over one-second intervals during the test.
The timer works best for rates under 36000 requests/hour, however your mileage might vary [see monitoring section below if your goals are vastly different].
Best location of a Precise Throughput Timer in a Test Plan
As you might know, the timers are inherited by all the siblings and their child elements. That is why one of the best places forPrecise Throughput Timer is under the first element in a test loop. For instance, you might add a dummy sampler at the beginning, and place the timer under that dummy sampler
Produced schedule
Precise Throughput Timer models Poisson arrivals schedule. That schedule often happens in a real-life, so it makes sense to use that for load testing. For instance, it naturally might generate samples that are close together thus it might reveal concurrency issues. Even if you manage to generate Poisson arrivals with , it would be susceptible to the issues listed below. For instance, true Poisson arrivals might have indefinitely long pause, and that is not practical for load testing. For instance, "regular" Poisson arrivals with 1 per second rate might end up with 50 samples over 60 second long test.
converges to the specified rate, however it tends to produce samples at even intervals.
Ramp-up and startup spike
You might used "ramp-up" or similar approaches to avoid a spike at the test start. For instance, if you configure to have 100 threads, and set Ramp-up Period to 0 [or to a small number], then all the threads would start at the same time, and it would produce an unwanted spike of the load. On top of that, if you set Ramp-up Period too high, it might result in "too few" threads being available at the very beginning to achieve the required load.
Precise Throughput Timer schedules executions in a random way, so it can be used to generate constant load, and it is recommended to set bothRamp-up Period and Delay to 0.
Multiple thread groups starting at the same time
A variation of Ramp-up issue might appear when includes multiple s. To mitigate that issue one typically adds "random" delay to each so threads start at different times.
Precise Throughput Timer avoids that issue since it schedules executions in a random way. You do not need to add extra random delays to mitigate startup spike
Number of iterations per hour
One of the basic requirements is to issue N samples per M minutes. Let it be 60 iterations per hour. Business customers would not understand if you report load test results with 57 executions "just because the random was random". In order to generate 60 iterations per hour, you need to configure as follows [other parameters could be left with their default values]
- Target throughput [samples]: 60
- Throughput period [seconds]: 3600
- Test duration [seconds]: 3600
The first two options set the throughput. Even though 60/3600, 30/1800, and 120/7200 represent exactly the same load level, pick the one that represents business requirements better. For instance, if the requirement is to test for "60 sample per hour", then set 60/3600. If the requirement is to test "1 sample per minute", then set 1/60.
Test duration [seconds] is there so the timer ensures exact number of samples for a given test duration. Precise Throughput Timer creates a schedule for the samples at the test startup. For instance, if you wish to perform 5 minutes test with 60 per hour throughput, you would set Test duration [seconds] to 300. This enables to configure throughput in a business-friendly way. Note: Test duration [seconds] does not limit test duration. It is just a hint for the timer.
Number of threads and think times
One of the common pitfalls is to adjust number of threads and think times in order to end up with the desired throughput. Even though it might work, that approach results in lots of time spent on the test runs. It might require to adjust threads and delays again when new application version arrives.
Precise Throughput Timer enables to set throughput goal and go for it no matter how well application performs. In order to do that, Precise Throughput Timer creates a schedule at the test startup, then it uses that schedule to release threads. The main driver for the think times and number of threads should be business requirements, not the desire to match throughput somehow.
For instance, if you application is used by support engineers in a call center. Suppose there are 2 engineers in the call center, and the target throughput is 1 per minute. Suppose it takes 4 minutes for the engineer to read and review the web page. For that case you should set 2 threads in the group, use 4 minutes for think time delays, and specify 1 per minute in Precise Throughput Timer. Of course it would result in something around 2samples/4minutes=0.5 per minute and the result of such a test means "you need more support engineers in a call center" or "you need to reduce the time it takes an engineer to fulfill a task".
Testing low rates and repeatable tests
Testing at low rates [e.g. 60 per hour] requires to know the desired test profile. For instance, if you need to inject load at even intervals [e.g. 60 seconds in between] then you'd better use . However, if you need to have randomized schedule [e.g. to model real users that execute reports], then Precise Throughput Timer is your friend.
When comparing outcomes of multiple load tests, it is useful to be able to repeat exactly the same test profile. For instance, if action X [e.g. "Profit Report"] is invoked after 5 minutes of the test start, then it would be nice to replicate that pattern for subsequent test executions. Replicating the same load pattern simplifies analysis of the test results [e.g. CPU% chart].
Random seed [change from 0 to random] enables to control the seed value that is used by Precise Throughput Timer. By default it is initialized with 0 and that means random seed is used for each test execution. If you need to have repeatable load pattern, then changeRandom seed so some random value. The general advice is to use non-zero seed, and "0 by default" is an implementation limit.
Note: when using multiple thread groups with same throughput rates and same non-zero seed it might result in unwanted firing the samples at the same time.
Testing high rates and/or long test durations
Precise Throughput Timer generates the schedule and keeps it in memory. In most cases it should not be a problem, however, remember that you might want to keep the schedule shorter than 1'000'000 samples. It takes ~200ms to generate a schedule for 1'000'000 samples, and the schedule consumes 8 megabytes in the heap. Schedule for 10 million entries takes 1-2 second to build and it consumes 80 megabytes in the heap.
For instance, if you want to perform 2-week long test with 5'000 per hour rate, then you probably want to have exactly 5'000 samples for each hour. You can set Test duration [seconds] property of the timer of the timer to 1 hour. Then the timer would create a schedule of 5'000 samples for an hour, and when the schedule is exhausted, the timer would generate a schedule for the next hour.
At the same time, you can set Test duration [seconds] to 2 weeks, and the timer would generate a schedule with168'000 samples = 2 weeks * 5'000 samples/hour = 2*7*24*500. The schedule would take ~30ms to generate, and it would consume a little more than 1 megabyte.
Bursty load
There might be a case when all the samples should come in pairs, triples, etc. Certain cases might be solved via , howeverPrecise Throughput Timer has native way to issue requests in packs. This behavior is disabled by default, and it is controlled with "Batched departures" settings
- Number of threads in the batch [threads]. Specifies the number of samples in a batch. Note the overall number of samples will still be in line with Target Throughput
- Delay between threads in the batch [ms]. For instance, if set to 42, and the batch size is 3, then threads will depart at x, x+42ms, x+84ms
Variable load rate
Even though property values [e.g. throughput] can be defined via expressions, it is recommended to keep the value more or less the same through the test, as it takes time to recompute the new schedule to adapt new values.
Monitoring
As next schedule is generated, Precise Throughput Timer logs a message to jmeter.log:2018-01-04 17:34:03,635 INFO o.a.j.t.ConstantPoissonProcessGenerator: Generated 21 timings [... 20 required, rate 1.0, duration 20, exact lim 20000, i21] in 0 ms. First 15 events will be fired at: 1.1869653574244292 [+1.1869653574244292], 1.4691340403043207 [+0.2821686828798915], 3.638151706179226 [+2.169017665874905], 3.836357090410566 [+0.19820538423134026], 4.709330071408575 [+0.8729729809980085], 5.61330076999953 [+0.903970698590955], ...This shows that schedule generation took 0ms, and it shows absolute timestamps in seconds. In the case above, the rate was set to be 1 per second, and the actual timestamps became 1.2 sec, 1.5 sec, 3.6 sec, 3.8 sec, 4.7 sec, and so on.
Screenshot of Control-Panel of Precise Throughput Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree
No
Target throughput [in samples per 'throughput period']
Maximum number of samples you want to obtain per "throughput period", including all threads in group, from all affected samplers.
Yes
Throughput period [seconds]
Throughput period. For example, if "throughput" is set to 42 and "throughput period" to 21 sec, then you'll get 2 samples per second.
Yes
Test duration [seconds]
This is used to ensure you'll get throughput*duration samples during "test duration" timeframe.
Yes
Number of threads in the batch [threads]
If the value exceeds 1, then multiple threads depart from the timer simultaneously. Average throughput still meets "throughput" value.
Yes
Delay between threads in the batch [ms]
For instance, if set to 42, and the batch size is 3, then threads will depart at x, x+42ms, x+84ms.
Yes
Random seed [change from 0 to random]
Note: different timers should better have different seed values. Constant seed ensures timer generates the same delays each test start. The value of "0" means the timer is truly random [non-repeatable from one execution to another]..
Yes
Synchronizing Timer
The purpose of the SyncTimer is to block threads until X number of threads have been blocked, and then they are all released at once. A SyncTimer can thus create large instant loads at various points of the test plan.
Screenshot of Control-Panel of Synchronizing Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree.
No
Number of Simultaneous Users to Group by
Number of threads to release at once. Setting it to 0 is equivalent to setting it to Number of threads in Thread Group.
Yes
Timeout in milliseconds
If set to 0, Timer will wait for the number of threads to reach the value in "Number of Simultaneous Users to Group". If superior to 0, then timer will wait at max "Timeout in milliseconds" for the number of Threads. If after the timeout interval the number of users waiting is not reached, timer will stop waiting. Defaults to 0
No
If timeout in milliseconds is set to 0 and number of threads never reaches "Number of Simultaneous Users to Group by" then Test will pause infinitely. Only a forced stop will stop it. Setting Timeout in milliseconds is an option to consider in this case.
Synchronizing timer blocks only within one JVM, so if using Distributed testing ensure you never set "Number of Simultaneous Users to Group by" to a value superior to the number of users of its containing Thread group considering 1 injector only.
BeanShell Timer
The BeanShell Timer can be used to generate a delay.
For full details on using BeanShell, please see the BeanShell website.
Migration to +Groovy is highly recommended for performance, support of new Java features and limited maintenance of the BeanShell library.
The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.
Screenshot of Control-Panel of BeanShell Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree. The name is stored in the script variable Label
No
Reset bsh.Interpreter before each call
If this option is selected, then the interpreter will be recreated for each sample. This may be necessary for some long running scripts. For further information, see .
Yes
Parameters
Parameters to pass to the BeanShell script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- bsh.args - String array containing parameters, split on white-space
No
Script file
A file containing the BeanShell script to run. The file name is stored in the script variable FileName The return value is used as the number of milliseconds to wait.
No
Script
The BeanShell script. The return value is used as the number of milliseconds to wait.
Yes [unless script file is provided]
Before invoking the script, some variables are set up in the BeanShell interpreter:
- log - [Logger] - can be used to write to the log file
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
8
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- prev - [SampleResult] - gives access to the previous SampleResult [if any]
For details of all the methods available on each of the above variables, please check the Javadoc
If the property beanshell.timer.init is defined, this is used to load an initialisation file, which can be used to define methods etc. for use in the BeanShell script.
JSR223 Timer
The JSR223 Timer can be used to generate a delay using a JSR223 scripting language,
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
ScriptLanguage
The scripting language to be used.
Yes
Parameters
Parameters to pass to the script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- args - String array containing parameters, split on white-space
No
Script file
A file containing the script to run, if a relative file path is used, then it will be relative to directory referenced by "user.dir" System property The return value is converted to a long integer and used as the number of milliseconds to wait.
No
Script compilation caching
Unique String across Test Plan that JMeter will use to cache result of Script compilation if language used supports Compilable interface [Groovy is one of these, java, beanshell and javascript are not]
See note in JSR223 Sampler Java System property if you're using Groovy without checking this option
No
Script
The script. The return value is used as the number of milliseconds to wait.
Yes [unless script file is provided]
Before invoking the script, some variables are set up in the script interpreter:
- log - [Logger] - can be used to write to the log file
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
9
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- sampler - [Sampler] - the current Sampler
- Label - the name of the Timer
- FileName - the file name [if any]
- OUT - System.out
For details of all the methods available on each of the above variables, please check the Javadoc
Poisson Random Timer
This timer pauses each thread request for a random amount of time, with most of the time intervals occurring near a particular value. The total delay is the sum of the Poisson distributed value, and the offset value.
Note: if you want to model Poisson arrivals, consider using instead.
Screenshot of Control-Panel of Poisson Random Timer
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree
No
Lambda
Lambda value in milliseconds.
Yes
Constant Delay Offset
Number of milliseconds to pause in addition to the random delay.
Yes
18.7 Pre Processors
Preprocessors are used to modify the Samplers in their scope.
HTML Link Parser
This modifier parses HTML response from the server and extracts links and forms. A URL test sample that passes through this modifier will be examined to see if it "matches" any of the links or forms extracted from the immediately previous response. It would then replace the values in the URL test sample with appropriate values from the matching link or form. Perl-type regular expressions are used to find matches.
Screenshot of Control-Panel of HTML Link Parser
Matches are performed using protocol, host, path and parameter names. The target sampler cannot contain parameters that are not in the response links.
If using distributed testing, ensure you switch mode [see jmeter.properties] so that it's not a stripping one, see Bug 56376
Spidering Example
Consider a simple example: let's say you wanted JMeter to "spider" through your site, hitting link after link parsed from the HTML returned from your server [this is not actually the most useful thing to do, but it serves as a good example]. You would create a , and add the "HTML Link Parser" to it. Then, create an HTTP Request, and set the domain to ".*", and the path likewise. This will cause your test sample to match with any link found on the returned pages. If you wanted to restrict the spidering to a particular domain, then change the domain value to the one you want. Then, only links to that domain will be followed.
Poll Example
A more useful example: given a web polling application, you might have a page with several poll options as radio buttons for the user to select. Let's say the values of the poll options are very dynamic - maybe user generated. If you wanted JMeter to test the poll, you could either create test samples with hardcoded values chosen, or you could let the HTML Link Parser parse the form, and insert a random poll option into your URL test sample. To do this, follow the above example, except, when configuring your Web Test controller's URL options, be sure to choose "POST" as the method. Put in hard-coded values for the domain, path, and any additional form parameters. Then, for the actual radio button parameter, put in the name [let's say it's called "poll_choice"], and then ".*" for the value of that parameter. When the modifier examines this URL test sample, it will find that it "matches" the poll form [and it shouldn't match any other form, given that you've specified all the other aspects of the URL test sample], and it will replace your form parameters with the matching parameters from the form. Since the regular expression ".*" will match with anything, the modifier will probably have a list of radio buttons to choose from. It will choose at random, and replace the value in your URL test sample. Each time through the test, a new random value will be chosen.
Figure 18 - Online Poll Example
One important thing to remember is that you must create a test sample immediately prior that will return an HTML page with the links and forms that are relevant to your dynamic test sample.
HTTP URL Re-writing Modifier
This modifier works similarly to the HTML Link Parser, except it has a specific purpose for which it is easier to use than the HTML Link Parser, and more efficient. For web applications that use URL Re-writing to store session ids instead of cookies, this element can be attached at the ThreadGroup level, much like the . Simply give it the name of the session id parameter, and it will find it on the page and add the argument to every request of that ThreadGroup.
Alternatively, this modifier can be attached to select requests and it will modify only them. Clever users will even determine that this modifier can be used to grab values that elude the .
Screenshot of Control-Panel of HTTP URL Re-writing Modifier
Parameters
Attribute
Description
Required
Name
Descriptive name given to this element in the test tree.
No
Session Argument Name
The name of the parameter to grab from previous response. This modifier will find the parameter anywhere it exists on the page, and grab the value assigned to it, whether it's in an HREF or a form.
Yes
Path Extension
Some web apps rewrite URLs by appending a semi-colon plus the session id parameter. Check this box if that is so.
No
Do not use equals in path extension
Some web apps rewrite URLs without using an "\=" sign between the parameter name and value [such as Intershop Enfinity].
No
Do not use questionmark in path extension
Prevents the query string to end up in the path extension [such as Intershop Enfinity].
No
Cache Session Id?
Should the value of the session Id be saved for later use when the session Id is not present?
Yes
URL Encode
URL Encode value when writing parameter
No
If using distributed testing, ensure you switch mode [see jmeter.properties] so that it's not a stripping one, see Bug 56376.
User Parameters
Allows the user to specify values for User Variables specific to individual threads.
User Variables can also be specified in the Test Plan but not specific to individual threads. This panel allows you to specify a series of values for any User Variable. For each thread, the variable will be assigned one of the values from the series in sequence. If there are more threads than values, the values get re-used. For example, this can be used to assign a distinct user id to be used by each thread. User variables can be referenced in any field of any JMeter Component.
The variable is specified by clicking the Add Variable button in the bottom of the panel and filling in the Variable name in the 'Name:' column. To add a new value to the series, click the 'Add User' button and fill in the desired value in the newly added column.
Values can be accessed in any test component in the same thread group, using the function syntax: ${variable}.
See also the element, which is more suitable for large numbers of parameters
Screenshot of Control-Panel of User Parameters
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Update Once Per Iteration
A flag to indicate whether the User Parameters element should update its variables only once per iteration. if you embed functions into the UP, then you may need greater control over how often the values of the variables are updated. Keep this box checked to ensure the values are updated each time through the UP's parent controller. Uncheck the box, and the UP will update the parameters for every sample request made within its .
Yes
BeanShell PreProcessor
The BeanShell PreProcessor allows arbitrary code to be applied before taking a sample.
For full details on using BeanShell, please see the BeanShell website.
Migration to +Groovy is highly recommended for performance, support of new Java features and limited maintenance of the BeanShell library.
The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.
Screenshot of Control-Panel of BeanShell PreProcessor
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree. The name is stored in the script variable Label
No
Reset bsh.Interpreter before each call
If this option is selected, then the interpreter will be recreated for each sample. This may be necessary for some long running scripts. For further information, see .
Yes
Parameters
Parameters to pass to the BeanShell script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- bsh.args - String array containing parameters, split on white-space
No
Script file
A file containing the BeanShell script to run. The file name is stored in the script variable FileName
No
Script
The BeanShell script. The return value is ignored.
Yes [unless script file is provided]
Before invoking the script, some variables are set up in the BeanShell interpreter:
- log - [Logger] - can be used to write to the log file
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
9
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- prev - [SampleResult] - gives access to the previous SampleResult [if any]
- sampler - [Sampler]- gives access to the current sampler
For details of all the methods available on each of the above variables, please check the Javadoc
If the property beanshell.preprocessor.init is defined, this is used to load an initialisation file, which can be used to define methods etc. for use in the BeanShell script.
JSR223 PreProcessor
The JSR223 PreProcessor allows JSR223 script code to be applied before taking a sample.
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Language
The JSR223 language to be used
Yes
Parameters
Parameters to pass to the script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- args - String array containing parameters, split on white-space
No
Script file
A file containing the script to run, if a relative file path is used, then it will be relative to directory referenced by "user.dir" System property
No
Script compilation caching
Unique String across Test Plan that JMeter will use to cache result of Script compilation if language used supports Compilable interface [Groovy is one of these, java, beanshell and javascript are not]
See note in JSR223 Sampler Java System property if you're using Groovy without checking this option
No
Script
The script to run.
Yes [unless script file is provided]
The following JSR223 variables are set up for use by the script:
- log - [Logger] - can be used to write to the log file
- Label - the String Label
- FileName - the script file name [if any]
- Parameters - the parameters [as a String]
- args - the parameters as a String array [split on whitespace]
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables: "Redirect requested but followRedirects is disabled" 6
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- sampler - [Sampler]- gives access to the current sampler
- OUT - System.out - e.g. OUT.println["message"]
For details of all the methods available on each of the above variables, please check the Javadoc
JDBC PreProcessor
The JDBC PreProcessor enables you to run some SQL statement just before a sample runs. This can be useful if your JDBC Sample requires some data to be in DataBase and you cannot compute this in a setup Thread group. For details, see .
See the following Test plan:
In the linked test plan, "Create Price Cut-Off" JDBC PreProcessor calls a stored procedure to create a Price Cut-Off in Database, this one will be used by "Calculate Price cut off".
Create Price Cut-Off Preprocessor
RegEx User Parameters
Allows to specify dynamic values for HTTP parameters extracted from another HTTP Request using regular expressions. RegEx User Parameters are specific to individual threads.
This component allows you to specify reference name of a regular expression that extracts names and values of HTTP request parameters. Regular expression group numbers must be specified for parameter's name and also for parameter's value. Replacement will only occur for parameters in the Sampler that uses this RegEx User Parameters which name matches
Screenshot of Control-Panel of RegEx User Parameters
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Regular Expression Reference Name
Name of a reference to a regular expression
Yes
Parameter names regexp group number
Group number of regular expression used to extract parameter names
Yes
Parameter values regex group number
Group number of regular expression used to extract parameter values
Yes
Regexp Example
Suppose we have a request which returns a form with 3 input parameters and we want to extract the value of 2 of them to inject them in next request
1. Create Post Processor Regular Expression for first HTTP Request
  - refName - set name of a regular expression Expression [listParams]
  - regular expression - expression that will extract input names and input values attributes
```
Ex: input name="[\["\]+?]" value="[\["\]+?]"  
```
  - template \- would be empty
  - match nr \- \-1 [in order to iterate through all the possible matches]
2. Create Pre Processor RegEx User Parameters for second HTTP Request
  - refName - set the same reference name of a regular expression, would be listParams in our example
  - parameter names group number - group number of regular expression for parameter names, would be 1 in our example
  - parameter values group number - group number of regular expression for parameter values, would be 2 in our example
See also the element, which is used to extract parameters names and values
Sample Timeout
This Pre-Processor schedules a timer task to interrupt a sample if it takes too long to complete. The timeout is ignored if it is zero or negative. For this to work, the sampler must implement Interruptible. The following samplers are known to do so: AJP, BeanShell, FTP, HTTP, Soap, AccessLog, MailReader, JMS Subscriber, TCPSampler, TestAction, JavaSampler
The test element is intended for use where individual timeouts such as Connection Timeout or Response Timeout are insufficient, or where the Sampler does not support timeouts. The timeout should be set sufficiently long so that it is not triggered in normal tests, but short enough that it interrupts samples that are stuck.
[By default, JMeter uses a Callable to interrupt the sampler. This executes in the same thread as the timer, so if the interrupt takes a long while, it may delay the processing of subsequent timeouts. This is not expected to be a problem, but if necessary the property InterruptTimer.useRunnablecan be set to true to use a separate Runnable thread instead of the Callable.]
Screenshot of Control-Panel of Sample Timeout
Parameters
Attribute
Description
Required
Name
Descriptive name for this timer that is shown in the tree.
No
Sample Timeout
If the sample takes longer to complete, it will be interrupted.
Yes
18.8 Post-Processors
As the name suggests, Post-Processors are applied after samplers. Note that they are applied to all the samplers in the same scope, so to ensure that a post-processor is applied only to a particular sampler, add it as a child of the sampler.
Note: Unless documented otherwise, Post-Processors are not applied to sub-samples [child samples] - only to the parent sample. In the case of JSR223 and BeanShell post-processors, the script can retrieve sub-samples using the methodprev.getSubResults[] which returns an array of SampleResults. The array will be empty if there are none.
Post-Processors are run before Assertions, so they do not have access to any Assertion Results, nor will the sample status reflect the results of any Assertions. If you require access to Assertion Results, try using a Listener instead. Also note that the variable JMeterThread.last_sample_ok is set to "true" or "false" after all Assertions have been run.
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.
Screenshot of Control-Panel of Regular Expression Extractor
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - extraction is to be applied to the contents of the named variable
Matching is applied to all qualifying samples in turn. For example if there is a main sample and 3 sub-samples, each of which contains a single match for the regex, [i.e. 4 matches in total]. For match number = 3, Sub-samples only, the extractor will match the 3rd sub-sample. For match number = 3, Main sample and sub-samples, the extractor will match the 2nd sub-sample [1st match is main sample]. For match number = 0 or negative, all qualifying samples will be processed. For match number > 0, matching will stop as soon as enough matches have been found.
Yes
Field to check
The following fields can be checked:
- Body - the body of the response, e.g. the content of a web-page [excluding headers]
- Body [unescaped] - the body of the response, with all Html escape codes replaced. Note that Html escapes are processed without regard to context, so some incorrect substitutions may be made. Note that this option highly impacts performances, so use it only when absolutely necessary and be aware of its impacts
- Body as a Document - the extract text from various type of documents via Apache Tika [see Document view section]. Note that the Body as a Document option can impact performances, so ensure it is OK for your test
- Request Headers - may not be present for non-HTTP samples
- Response Headers - may not be present for non-HTTP samples
- URL
- Response Code - e.g. 200
- Response Message - e.g. OK
Headers can be useful for HTTP samples; it may not be present for other sample types.
Yes
Name of created variable
The name of the JMeter variable in which to store the result. Also note that each group is stored as [refname]_g#, where [refname] is the string you entered as the reference name, and # is the group number, where group 0 is the entire match, group 1 is the match from the first set of parentheses, etc.
Yes
Regular Expression
The regular expression used to parse the response data. This must contain at least one set of parentheses "[]" to capture a portion of the string, unless using the group $0$. Do not enclose the expression in / / - unless of course you want to match these characters as well.
Yes
Template
The template used to create a string from the matches found. This is an arbitrary string with special elements to refer to groups within the regular expression. The syntax to refer to a group is: '$1$' to refer to group 1, '$2$' to refer to group 2, etc. $0$ refers to whatever the entire expression matches.
Yes
Match No. [0 for Random]
Indicates which match to use. The regular expression may match multiple times.
- Use a value of zero to indicate JMeter should choose a match at random.
- A positive number N means to select the nth match.
- Negative numbers are used in conjunction with the - see below.
Yes
Default Value
If the regular expression does not match, then the reference variable will be set to the default value. This is particularly useful for debugging tests. If no default is provided, then it is difficult to tell whether the regular expression did not match, or the RE element was not processed or maybe the wrong variable is being used.
However, if you have several test elements that set the same variable, you may wish to leave the variable unchanged if the expression does not match. In this case, remove the default value once debugging is complete.
No, but recommended
Use empty default value
If the checkbox is checked and Default Value is empty, then JMeter will set the variable to empty string instead of not setting it. Thus when you will for example use ${var} [if Reference Name is var] in your Test Plan, if the extracted value is not found then${var} will be equal to empty string instead of containing ${var} which may be useful if extracted value is optional.
No
If the match number is set to a non-negative number, and a match occurs, the variables are set as follows:
- refName - the value of the template
- refName_gn, where n\=0,1,2 - the groups for the match
- refName_g - the number of groups in the Regex [excluding 0]
If no match occurs, then the refName variable is set to the default [unless this is absent]. Also, the following variables are removed:
- refName_g0
- refName_g1
- refName_g
If the match number is set to a negative number, then all the possible matches in the sampler data are processed. The variables are set as follows:
- refName_matchNr - the number of matches found; could be 0
- refName_n, where n \= 1, 2, 3 etc. - the strings as generated by the template
- refName_n_gm, where m\=0, 1, 2 - the groups for match n
- refName - always set to the default value
- refName_gn - not set
Note that the refName variable is always set to the default value in this case, and the associated group variables are not set.
See also for some examples of how to specify modifiers, and for further information on JMeter regular expressions.
Allows the user to extract values from a server HTML response using a CSS Selector syntax. As a post-processor, this element will execute after each Sample request in its scope, applying the CSS/JQuery expression, extracting the requested nodes, extracting the node as text or attribute value and store the result into the given variable name.
Screenshot of Control-Panel of CSS Selector Extractor
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - extraction is to be applied to the contents of the named variable
Matching is applied to all qualifying samples in turn. For example if there is a main sample and 3 sub-samples, each of which contains a single match for the regex, [i.e. 4 matches in total]. For match number = 3, Sub-samples only, the extractor will match the 3rd sub-sample. For match number = 3, Main sample and sub-samples, the extractor will match the 2nd sub-sample [1st match is main sample]. For match number = 0 or negative, all qualifying samples will be processed. For match number > 0, matching will stop as soon as enough matches have been found.
Yes
CSS Selector Implementation
2 Implementations for CSS/JQuery based syntax are supported:
- JSoup
- Jodd-Lagarto [CSSelly]
If selector is set to empty, default implementation[JSoup] will be used.
False
Name of created variable
The name of the JMeter variable in which to store the result.
Yes
CSS/JQuery expression
The CSS/JQuery selector used to select nodes from the response data. Selector, selectors combination and pseudo-selectors are supported, examples:
- E[foo] - an E element with a "foo" attribute
- ancestor child - child elements that descend from ancestor, e.g. .body p finds p elements anywhere under a block with class "body"
- :lt[n] - find elements whose sibling index [i.e. its position in the DOM tree relative to its parent] is less than n; e.g. td:lt[3]
- :contains[text] - find elements that contain the given text. The search is case-insensitive; e.g. p:contains[jsoup]
- …
For more details on syntax, see:
- JSoup
- Jodd-Lagarto [CSSelly]
Yes
Attribute
Name of attribute [as per HTML syntax] to extract from nodes that matched the selector. If empty, then the combined text of this element and all its children will be returned. This is the equivalent function for JSoup if an attribute is set.
CSS Extractor with attribute value set
If empty this is the equivalent of function for JSoup if not value is set for attribute.
CSS Extractor with no attribute set
false
Match No. [0 for Random]
Indicates which match to use. The CSS/JQuery selector may match multiple times.
- Use a value of zero to indicate JMeter should choose a match at random.
- A positive number N means to select the nth match.
- Negative numbers are used in conjunction with the - see below.
Yes
Default Value
If the expression does not match, then the reference variable will be set to the default value. This is particularly useful for debugging tests. If no default is provided, then it is difficult to tell whether the expression did not match, or the CSS/JQuery element was not processed or maybe the wrong variable is being used.
However, if you have several test elements that set the same variable, you may wish to leave the variable unchanged if the expression does not match. In this case, remove the default value once debugging is complete.
No, but recommended
Use empty default value
If the checkbox is checked and Default Value is empty, then JMeter will set the variable to empty string instead of not setting it. Thus when you will for example use ${var} [if Reference Name is var] in your Test Plan, if the extracted value is not found then${var} will be equal to empty string instead of containing ${var} which may be useful if extracted value is optional.
No
If the match number is set to a non-negative number, and a match occurs, the variables are set as follows:
- refName - the value of the template
If no match occurs, then the refName variable is set to the default [unless this is absent].
If the match number is set to a negative number, then all the possible matches in the sampler data are processed. The variables are set as follows:
- refName_matchNr - the number of matches found; could be 0
- refName_n, where n \= 1, 2, 3, etc. - the strings as generated by the template
- refName - always set to the default value
Note that the refName variable is always set to the default value in this case.
This test element allows the user to extract value[s] from structured response - XML or [X]HTML - using XPath2 query language.
Screenshot of Control-Panel of XPath2 Extractor
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - extraction is to be applied to the contents of the named variable
XPath matching is applied to all qualifying samples in turn, and all the matching results will be returned.
Yes
Return entire XPath fragment instead of text content?
If selected, the fragment will be returned rather than the text content. For example //title would return "Apache JMeter" rather than "Apache JMeter". In this case, //title/text[] would return "Apache JMeter".
Yes
Name of created variable
The name of the JMeter variable in which to store the result.
Yes
XPath Query
Element query in XPath 2.0 language. Can return more than one match.
Yes
Match No. [0 for Random]
If the XPath Path query leads to many results, you can choose which one[s] to extract as Variables:
- 0: means random [default value]
- -1 means extract all results, they will be named as _N [where N goes from 1 to Number of results]
- X: means extract the Xth result. If this Xth is greater than number of matches, then nothing is returned. Default value will be used
No
Default Value
Default value returned when no match found. It is also returned if the node has no value and the fragment option is not selected.
yes
Namespaces aliases list
List of namespaces aliases you want to use to parse the document, one line per declaration. You must specify them as follow: prefix=namespace. This implementation makes it easier to use namespaces than with the old XPathExtractor version.
No
To allow for use in a , it works exactly the same as the above XPath Extractor
XPath2 Extractor provides some interestings tools such as an improved syntax and much more functions than in its first version.
Here are some exemples:
abs[/book/page[2]]extracts 2nd absolute value of the page from a bookavg[/librarie/book/page]extracts the average number of page from all the books in the librariescompare[/book[1]/page[2],/book[2]/page[2]]return Integer value equal 0 to if the 2nd page of the first book is equal to the 2nd page of the 2nd book, else return -1.
To see more information about these functions, please check xPath2 functions
This test element allows the user to extract value[s] from structured response - XML or [X]HTML - using XPath query language.
Since JMeter 5.0, you should use as it provides better and easier namespace management, better performances and support for XPath 2.0
Screenshot of Control-Panel of XPath Extractor
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - extraction is to be applied to the contents of the named variable
XPath matching is applied to all qualifying samples in turn, and all the matching results will be returned.
Yes
Use Tidy [tolerant parser]
If checked use Tidy to parse HTML response into XHTML.
- "Use Tidy" should be checked on for HTML response. Such response is converted to valid XHTML [XML compatible HTML] using Tidy
- "Use Tidy" should be unchecked for both XHTML or XML response [for example RSS]
For HTML, CSS Selector Extractor is the correct and performing solution. Don't use XPath for HTML extractions.
Yes
Quiet
Sets the Tidy Quiet flag
If Tidy is selected
Report Errors
If a Tidy error occurs, then set the Assertion accordingly
If Tidy is selected
Show warnings
Sets the Tidy showWarnings option
If Tidy is selected
Use Namespaces
If checked, then the XML parser will use namespace resolution.[see note below on NAMESPACES] Note that currently only namespaces declared on the root element will be recognised. See below for user-definition of additional workspace names.
If Tidy is not selected
Validate XML
Check the document against its schema.
If Tidy is not selected
Ignore Whitespace
Ignore Element Whitespace.
If Tidy is not selected
Fetch External DTDs
If selected, external DTDs are fetched.
If Tidy is not selected
Return entire XPath fragment instead of text content?
If selected, the fragment will be returned rather than the text content. For example //title would return "Apache JMeter" rather than "Apache JMeter". In this case, //title/text[] would return "Apache JMeter".
Yes
Name of created variable
The name of the JMeter variable in which to store the result.
Yes
XPath Query
Element query in XPath language. Can return more than one match.
Yes
Match No. [0 for Random]
If the XPath Path query leads to many results, you can choose which one[s] to extract as Variables:
- 0: means random
- -1 means extract all results [default value], they will be named as _N [where N goes from 1 to Number of results]
- X: means extract the Xth result. If this Xth is greater than number of matches, then nothing is returned. Default value will be used
No
Default Value
Default value returned when no match found. It is also returned if the node has no value and the fragment option is not selected.
To allow for use in a , the following variables are set on return:
- refName - set to first [or only] match; if no match, then set to default
- refName_matchNr - set to number of matches [may be 0]
- refName_n - n\=1, 2, 3, etc. Set to the 1st, 2nd 3rd match etc.
Note: The next refName_n variable is set to null - e.g. if there are 2 matches, then refName_3 is set to null, and if there are no matches, then refName_1 is set to null.
XPath is query language targeted primarily for XSLT transformations. However it is useful as generic query language for structured data too. See XPath Reference or XPath specification for more information. Here are few examples:
/html/head/titleextracts title element from HTML response/book/page[2]extracts 2nd page from a book/book/pageextracts all pages from a book//form[@name='countryForm']//select[@name='country']/option[text[]='Czech Republic']]/@valueextracts value attribute of option element that match text 'Czech Republic' inside of select element with name attribute 'country' inside of form with name attribute 'countryForm'
When "Use Tidy" is checked on - resulting XML document may slightly differ from original HTML response:
- All elements and attribute names are converted to lowercase
- Tidy attempts to correct improperly nested elements. For example - original [incorrect] ul/font/li becomes correct ul/li/font
See Tidy homepage for more information.
NAMESPACES As a work-round for namespace limitations of the Xalan XPath parser [implementation on which JMeter is based] you need to:
- provide a Properties file [if for example your file is named namespaces.properties] which contains mappings for the namespace prefixes:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
4
- reference this file in user.properties file using the property:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
5
httpclient4.retrycount=3
4
httpclient4.retrycount=3
5
uri-for-namespacemynamespace
This test element allows the user to extract value[s] from JSON response using JMESPath query language.
Screenshot of Control-Panel of JSON JMESPath Extractor
In the XPATH Extractor we support to extract multiple xpaths at the same time, but in JMES Extractor only one JMES Expression can be entered at a time.
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - extraction is to be applied to the contents of the named variable
Yes
Name of created variable
The name of the JMeter variable in which to store the result.
Yes
JMESPath expressions
Element query in JMESPath query language. Can return the matched result.
Yes
Match No. [0 for Random]
If the JMESPath query leads to many results, you can choose which one[s] to extract as Variables:
- 0: means random
- -1 means extract all results [default value], they will be named as _N [where N goes from 1 to Number of results]
- X: means extract the Xth result. If this Xth is greater than number of matches, then nothing is returned. Default value will be used
No
Default Value
Default value returned when no match found. It is also returned if the node has no value and the fragment option is not selected.
JMESPath is a query language for JSON. It is described in an ABNF grammar with a complete specification. This ensures that the language syntax is precisely defined. See JMESPath Reference for more information. Here are also some examples JMESPath Example.
Result Status Action Handler
This test element allows the user to stop the thread or the whole test if the relevant sampler failed.
Screenshot of Control-Panel of Result Status Action Handler
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Action to be taken after a Sampler error
Determines what happens if a sampler error occurs, either because the sample itself failed or an assertion failed. The possible choices are:
- Continue - ignore the error and continue with the test
- Start next thread loop - does not execute samplers following the sampler in error for the current iteration and restarts the loop on next iteration
- Stop Thread - current thread exits
- Stop Test - the entire test is stopped at the end of any current samples.
- Stop Test Now - the entire test is stopped abruptly. Any current samplers are interrupted if possible.
No
BeanShell PostProcessor
The BeanShell PreProcessor allows arbitrary code to be applied after taking a sample.
BeanShell Post-Processor no longer ignores samples with zero-length result data
For full details on using BeanShell, please see the BeanShell website.
Migration to +Groovy is highly recommended for performance, support of new Java features and limited maintenance of the BeanShell library.
The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.
Screenshot of Control-Panel of BeanShell PostProcessor
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree. The name is stored in the script variable Label
No
Reset bsh.Interpreter before each call
If this option is selected, then the interpreter will be recreated for each sample. This may be necessary for some long running scripts. For further information, see .
Yes
Parameters
Parameters to pass to the BeanShell script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- bsh.args - String array containing parameters, split on white-space
No
Script file
A file containing the BeanShell script to run. The file name is stored in the script variable FileName
No
Script
The BeanShell script. The return value is ignored.
Yes [unless script file is provided]
The following BeanShell variables are set up for use by the script:
- log - [Logger] - can be used to write to the log file
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables:
  Define characters per second > 0 to emulate slow connections
httpclient.socket.http.cps=0

httpclient.socket.https.cps=0
9
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- prev - [SampleResult] - gives access to the previous SampleResult
- data - [byte []]- gives access to the current sample data
For details of all the methods available on each of the above variables, please check the Javadoc
If the property beanshell.postprocessor.init is defined, this is used to load an initialisation file, which can be used to define methods etc. for use in the BeanShell script.
JSR223 PostProcessor
The JSR223 PostProcessor allows JSR223 script code to be applied after taking a sample.
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Language
The JSR223 language to be used
Yes
Parameters
Parameters to pass to the script. The parameters are stored in the following variables:
- Parameters - string containing the parameters as a single variable
- args - String array containing parameters, split on white-space
No
Script file
A file containing the script to run, if a relative file path is used, then it will be relative to directory referenced by "user.dir" System property
No
Script compilation caching
Unique String across Test Plan that JMeter will use to cache result of Script compilation if language used supports Compilable interface [Groovy is one of these, java, beanshell and javascript are not]
See note in JSR223 Sampler Java System property if you're using Groovy without checking this option
No
Script
The script to run.
Yes [unless script file is provided]
Before invoking the script, some variables are set up. Note that these are JSR223 variables - i.e. they can be used directly in the script.
- log - [Logger] - can be used to write to the log file
- Label - the String Label
- FileName - the script file name [if any]
- Parameters - the parameters [as a String]
- args - the parameters as a String array [split on whitespace]
- ctx - [JMeterContext] - gives access to the context
- vars - [JMeterVariables] - gives read/write access to variables: "Redirect requested but followRedirects is disabled" 6
- props - [JMeterProperties - class java.util.Properties] - e.g. props.get["START.HMS"]; props.put["PROP1","1234"];
- prev - [SampleResult] - gives access to the previous SampleResult [if any]
- sampler - [Sampler]- gives access to the current sampler
- OUT - System.out - e.g. OUT.println["message"]
For details of all the methods available on each of the above variables, please check the Javadoc
JDBC PostProcessor
The JDBC PostProcessor enables you to run some SQL statement just after a sample has run. This can be useful if your JDBC Sample changes some data and you want to reset state to what it was before the JDBC sample run.
In the linked test plan, "JDBC PostProcessor" JDBC PostProcessor calls a stored procedure to delete from Database the Price Cut-Off that was created by PreProcessor.
JDBC PostProcessor
The JSON PostProcessor enables you extract data from JSON responses using JSON-PATH syntax. This post processor is very similar to Regular expression extractor. It must be placed as a child of HTTP Sampler or any other sampler that has responses. It will allow you to extract in a very easy way text content, see JSON Path syntax.
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
Main sample onlyonly applies to the main sampleSub-samples onlyonly applies to the sub-samplesMain sample and sub-samplesapplies to both.JMeter Variable Name to useextraction is to be applied to the contents of the named variable
Yes
Names of created variables
Semicolon separated names of variables that will contain the results of JSON-PATH expressions [must match number of JSON-PATH expressions]
Yes
JSON Path Expressions
Semicolon separated JSON-PATH expressions [must match number of variables]
Yes
Default Values
Semicolon separated default values if JSON-PATH expressions do not return any result[must match number of variables]
No
Match Numbers
For each JSON Path Expression, if the JSON Path query leads to many results, you can choose which one[s] to extract as Variables:
- 0: means random [Default Value]
- -1 means extract all results, they will be named as _N [where N goes from 1 to Number of results]
- X: means extract the Xth result. If this Xth is greater than number of matches, then nothing is returned. Default value will be used
The numbers have to be given as a Semicolon separated list. The number of elements in that list have to match the number of given JSON Path Expressions. If left empty, the value 0 will be used as default for every expression.
No
Compute concatenation var
If many results are found, plugin will concatenate them using ‘,’ separator and store it in a var named _ALL
No
JSON PostProcessor
Allows the user to extract values from a server response using left and right boundaries. As a post-processor, this element will execute after each Sample request in its scope, testing the boundaries, extracting the requested values, generate the template string, and store the result into the given variable name.
Screenshot of Control-Panel of Boundary Extractor
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Apply to:
This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.
- Main sample only - only applies to the main sample
- Sub-samples only - only applies to the sub-samples
- Main sample and sub-samples - applies to both.
- JMeter Variable Name to use - assertion is to be applied to the contents of the named variable
Matching is applied to all qualifying samples in turn. For example if there is a main sample and 3 sub-samples, each of which contains a single match test, [i.e. 4 matches in total]. For match number = 3, Sub-samples only, the extractor will match the 3rd sub-sample. For match number = 3, Main sample and sub-samples, the extractor will match the 2nd sub-sample [1st match is main sample]. For match number = 0 or negative, all qualifying samples will be processed. For match number > 0, matching will stop as soon as enough matches have been found.
Yes
Field to check
The following fields can be checked:
- Body - the body of the response, e.g. the content of a web-page [excluding headers]
- Body [unescaped] - the body of the response, with all Html escape codes replaced. Note that Html escapes are processed without regard to context, so some incorrect substitutions may be made. Note that this option highly impacts performances, so use it only when absolutely necessary and be aware of its impacts
- Body as a Document - the extract text from various type of documents via Apache Tika [see Document view section]. Note that the Body as a Document option can impact performances, so ensure it is OK for your test
- Request Headers - may not be present for non-HTTP samples
- Response Headers - may not be present for non-HTTP samples
- URL
- Response Code - e.g. 200
- Response Message - e.g. OK
Headers can be useful for HTTP samples; it may not be present for other sample types.
Yes
Name of created variable
The name of the JMeter variable in which to store the result. Also note that each group is stored as [refname]_g#, where [refname] is the string you entered as the reference name, and # is the group number, where group 0 is the entire match, group 1 is the match from the first set of parentheses, etc.
Yes
Left Boundary
Left boundary of value to find
No
Right Boundary
Right boundary of value to find
No
Match No. [0 for Random]
Indicates which match to use. The boundaries may match multiple times.
- Use a value of zero to indicate JMeter should choose a match at random.
- A positive number N means to select the nth match.
- Negative numbers are used in conjunction with the - see below.
Yes
Default Value
If the boundaries do not match, then the reference variable will be set to the default value. This is particularly useful for debugging tests. If no default is provided, then it is difficult to tell whether the boundaries did not match, or maybe the wrong variable is being used.
However, if you have several test elements that set the same variable, you may wish to leave the variable unchanged if the expression does not match. In this case, remove the default value once debugging is complete.
No, but recommended
If the match number is set to a non-negative number, and a match occurs, the variables are set as follows:
- refName - the value of the extraction
If no match occurs, then the refName variable is set to the default [unless this is absent].
If the match number is set to a negative number, then all the possible matches in the sampler data are processed. The variables are set as follows:
- refName_matchNr - the number of matches found; could be 0
- refName_n, where n \= 1, 2, 3 etc. - the strings as generated by the template
- refName_n_gm, where m\=0, 1, 2 - the groups for match n
- refName - always set to the default value
Note that the refName variable is always set to the default value in this case, and the associated group variables are not set.
If both left and right boundary are null, the whole data selected in scope is returned
18.9 Miscellaneous Features

Test Plan
The Test Plan is where the overall settings for a test are specified.
Static variables can be defined for values that are repeated throughout a test, such as server names. For example the variable SERVER could be defined as www.example.com, and the rest of the test plan could refer to it as ${SERVER}. This simplifies changing the name later.
If the same variable name is reused on one of more Configuration elements, the value is set to the last definition in the test plan [reading from top to bottom]. Such variables should be used for items that may change between test runs, but which remain the same during a test run.
Note that the Test Plan cannot refer to variables it defines.
If you need to construct other variables from the Test Plan variables, use a test element.
Selecting Functional Testing instructs JMeter to save the additional sample information - Response Data and Sampler Data - to all result files. This increases the resources needed to run a test, and may adversely impact JMeter performance. If more data is required for a particular sampler only, then add a Listener to it, and configure the fields as required.
The option does not affect CSV result files, which cannot currently store such information.
Also, an option exists here to instruct JMeter to run the serially rather than in parallel.
Run tearDown Thread Groups after shutdown of main threads: if selected, the tearDown groups [if any] will be run after graceful shutdown of the main threads. The tearDown threads won't be run if the test is forcibly stopped.
Test plan now provides an easy way to add classpath setting to a specific test plan. The feature is additive, meaning that you can add jar files or directories, but removing an entry requires restarting JMeter.
Note that this cannot be used to add JMeter GUI plugins, because they are processed earlier.
However it can be useful for utility jars such as JDBC drivers. The jars are only added to the search path for the JMeter loader, not for the system class loader.
JMeter properties also provides an entry for loading additional classpaths. In jmeter.properties, edit "user.classpath" or "plugin_dependency_paths" to include additional libraries. See and for details.
Screenshot of Control-Panel of Test Plan
Open Model Thread Group
This thread group is experimental, and it might change in the future releases. Please provide your feedback on what works and what could be improved.
Open Model Thread Group defines a pool of users that will execute a particular test case against the server. The users are generated according to the schedule.
The load profile consists of a sequence of constant, increasing or decreasing load. The basic configuration is rate[1/sec] random_arrivals[2 min] rate[3/sec] which means the load will increase linearly from one request per second to three requests per second during a period of two-minutes. If you omit rate at the end, then it will be set to the same value as that from the start. For example,rate[1/sec] random_arrivals[2 min] is exactly the same as rate[1/sec] random_arrivals[2 min] rate[1/sec]. That is why rate[1/sec] random_arrivals[2 min] random_arrivals[3 min] rate[4/sec] is exactly the same asrate[1/sec] random_arrivals[2 min] rate[1/sec] random_arrivals[3 min] rate[4/sec], so the load is one request per second during the first two minutes, after which it increases linearly from one request per second to four requests per second during three minutes.
Here are examples for using the schedule:
rate[10/sec] random_arrivals[1 min] rate[10/sec]constant load rate of ten requests per second during one minuterate[0] random_arrivals[1 min] rate[10/sec]linearly increase the load from zero requests per second to ten requests per second during one minuterate[0] random_arrivals[1 min] rate[10/sec] random_arrivals[1 min] rate[10/sec] random_arrivals[1 min] rate[0]linearly increase the load from zero requests per second to ten requests per second during one minute, then hold the load during one minute, then linearly decrease the load from ten requests per second to zero during one minuterate[10] random_arrivals[1 min] rate[10/sec] random_arrivals[1 min] rate[10/sec] random_arrivals[1 min] rate[0]linearly increase the load from zero requests per second to ten requests per second during one minute, then hold the load during one minute, then linearly decrease the load from ten requests per second to zero requests per second during one minuterate[10] random_arrivals[1 min] pause[2 sec] random_arrivals[1 min]run with constant load of ten requests per second during one minute, then make two second pause, then resume the load of ten requests per second for one minute
The following commands are available:
rate[/sec]configures target load rate. The following time units are supported: ms, sec, min, hour, day. You can omit time unit in case the rate is 0: rate[0] random_arrivals[ sec]configures random arrivals schedule with the given duration. The starting load rate is configured before random_arrivals, and the finish load rate is configured after random_arrivals. For example, 10 minute test from five requests per second at the beginning to fifteen request per second at the end could be configured as rate[5/sec] random_arrivals[10 min] rate[15/sec]. The implicit rate at the beginning of the test is 0. If the finish rate is not provided [or if several random_arrivals steps go one after another], then the load is constant. For instance, rate[3/sec] random_arrivals[1 min] random_arrivals[2 min] rate[6/sec] configures constant rate of three requests per second for the first minute, and then the load increases from three requests per second to six requests per second during the next two minutes. The time units are the same as in rate.even_arrivals[ sec]configures even arrivals [TODO: not implemented yet]. For instance, if the desired load is one request per second, then random_arrivals would lauch samples with exactly one second intervals.pause[ sec]configures a pause for the given duration. The rate is restored after the pause, so rate[2/sec] random_arrivals[5 sec] pause[5 sec] random_arrivals[5 sec] generates random arrivals with two requests per second rate, then a pause for five seconds [no new arrivals], then five more seconds with two requests per second rate. Note: pause duration is always honoured, even if all the scenarios are complete, and no new ones will be scheduled. For instance, if you use rate[1/sec] random_arrivals[1 min] pause[1 hour], the thread group would always last for sixty-one minutes no matter how much time do individual scenarios take./* Comments */can be used to clarify the schedule or temporary disable some steps. Comments cannot be nested.// line commentscan be used to clarify the schedule or temporary disable some steps. Line comment lasts till the end of the line.
The thread groups terminates threads as soon as the schedule ends. In other words, the threads are interrupted after all arrivals and pause intervals. If you want to let the threads complete safely, consider adding pause[5 min] at the end of the schedule. That will add five minutes for the threads to continue.
There are no special functions for generating the load profile in a loop, however, the default JMeter templating functions can be helpful for generating the schedule.
For example, the following pattern would generate a sequence of 10 steps where each step lasts 10 seconds: 10/sec, 20/sec, 30/sec, ...${__groovy[[1..10].collect { "rate[" + it*10 + "/sec] random_arrivals[10 sec] pause[1 sec]" }.join[" "]]} You can get variables from properties as follows:rate[${__P[beginRate,40]}] random_arrivals[${__P[testDuration, 10]} sec] rate[${__P[endRate,40]}]
Currently, the load profile is evaluated at the beginning of the test only, so if you use dynamic functions, then only the first result will be used.
Screenshot of Control-Panel of Open Model Thread Group
Parameters
Attribute
Description
Required
Name
Descriptive name for this thread group that is shown in the tree
No
Schedule
The expression that configures schedule. For example: rate[5/sec] random_arrivals[1 min] pause[5 sec]
Yes
Random Seed [change from 0 to random]
Note: different thread groups should better have different seed values. Constant seed ensures thread group generates the same delays each test start. The value of "0" means the schedule is truly random [non-repeatable from one execution to another]..
No
Thread Group
A Thread Group defines a pool of users that will execute a particular test case against your server. In the Thread Group GUI, you can control the number of users simulated [number of threads], the ramp up time [how long it takes to start all the threads], the number of times to perform the test, and optionally, a start and stop time for the test.
See also and .
When using the scheduler, JMeter runs the thread group until either the number of loops is reached or the duration/end-time is reached - whichever occurs first. Note that the condition is only checked between samples; when the end condition is reached, that thread will stop. JMeter does not interrupt samplers which are waiting for a response, so the end time may be delayed arbitrarily.
Screenshot of Control-Panel of Thread Group
Since JMeter 3.0, you can run a selection of Thread Group by selecting them and right clicking. A popup menu will appear:
Popup menu to start a selection of Thread Groups
Notice you have three options to run the selection of Thread Groups:
StartStart the selected thread groups onlyStart no pausesStart the selected thread groups only but without running the timersValidateStart the selected thread groups only using validation mode. Per default this runs the Thread Group in validation mode [see below]
Validation Mode: This mode enables rapid validation of a Thread Group by running it with one thread, one iteration, no timers and no Startup delay set to 0. Behaviour can be modified with some properties by setting in user.properties:
testplan_validation.nb_threads_per_thread_groupNumber of threads to use to validate a Thread Group, by default 1 testplan_validation.ignore_timersIgnore timers when validating the thread group of plan, by default 1 testplan_validation.number_iterationsNumber of iterations to use to validate a Thread Grouptestplan_validation.tpc_force_100_pctWhether to force Throughput Controller in percentage mode to run as if percentage was 100 %. Defaults to false
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Action to be taken after a Sampler error
Determines what happens if a sampler error occurs, either because the sample itself failed or an assertion failed. The possible choices are:
- Continue - ignore the error and continue with the test
- Start Next Thread Loop - ignore the error, start next loop and continue with the test
- Stop Thread - current thread exits
- Stop Test - the entire test is stopped at the end of any current samples.
- Stop Test Now - the entire test is stopped abruptly. Any current samplers are interrupted if possible.
No
Number of Threads
Number of users to simulate.
Yes
Ramp-up Period
How long JMeter should take to get all the threads started. If there are 10 threads and a ramp-up time of 100 seconds, then each thread will begin 10 seconds after the previous thread started, for a total time of 100 seconds to get the test fully up to speed.
The first thread will always start directly, so if you configured one thread, the ramp-up time is effectively zero. For the same reason, the tenth thread in the above example will actually be started after 90 seconds and not 100 seconds.
Yes
Same user on each iteration
If selected, cookie and cache data from the first sampler response are used in subsequent requests [requires a global Cookie and Cache Manager respectively]. If not selected, cookie and cache data from the first sampler response are not used in subsequent requests.
If not selected, a new connection will be opened between iterations which will result in increased response times and consume more resources [memory and cpu].
Yes
Loop Count
Number of times to perform the test case. Alternatively, "infinite" can be selected causing the test to run until manually stopped or end of the thread lifetime is reached.
Yes, unless Infinite is selected
Same user on each iteration
If selected, cookie and cache data from the first sampler response are used in subsequent requests [requires a global Cookie and Cache Manager respectively]. If not selected, cookie and cache data from the first sampler response are not used in subsequent requests.
If not selected, a new connection will be opened between iterations which will result in increased response times and consume more resources [memory and cpu].
Yes
Delay Thread creation until needed
If selected, threads are created only when the appropriate proportion of the ramp-up time has elapsed. This is most appropriate for tests with a ramp-up time that is significantly longer than the time to execute a single thread. I.e. where earlier threads finish before later ones start. If not selected, all threads are created when the test starts [they then pause for the appropriate proportion of the ramp-up time]. This is the original default, and is appropriate for tests where threads are active throughout most of the test.
Yes
Specify Thread lifetime
If selected, confines Thread operation time to the given bounds
Yes
Duration [seconds]
If the scheduler checkbox is selected, one can choose a relative end time. JMeter will use this to calculate the End Time.
No
Startup delay [seconds]
If the scheduler checkbox is selected, one can choose a relative startup delay. JMeter will use this to calculate the Start Time.
No
WorkBench

SSL Manager
The SSL Manager is a way to select a client certificate so that you can test applications that use Public Key Infrastructure [PKI]. It is only needed if you have not set up the appropriate System properties.
Choosing a Client Certificate
You may either use a Java Key Store [JKS] format key store, or a Public Key Certificate Standard
12 [PKCS12] file for your client certificates. There is a feature of the JSSE libraries that require you to have at least a six character password on your key [at least for the keytool utility that comes with your JDK].
To select the client certificate, choose from the menu bar. You will be presented with a file finder that looks for PKCS12 files by default. Your PKCS12 file must have the extension '.p12' for SSL Manager to recognize it as a PKCS12 file. Any other file will be treated like an average JKS key store. If JSSE is correctly installed, you will be prompted for the password. The text box does not hide the characters you type at this point -- so make sure no one is looking over your shoulder. The current implementation assumes that the password for the keystore is also the password for the private key of the client you want to authenticate as.
Or you can set the appropriate System properties - see the system.properties file.
The next time you run your test, the SSL Manager will examine your key store to see if it has at least one key available to it. If there is only one key, SSL Manager will select it for you. If there is more than one key, it currently selects the first key. There is currently no way to select other entries in the keystore, so the desired key must be the first.
Things to Look Out For
You must have your Certificate Authority [CA] certificate installed properly if it is not signed by one of the five CA certificates that ships with your JDK. One method to install it is to import your CA certificate into a JKS file, and name the JKS file "jssecacerts". Place the file in your JRE'slib/security folder. This file will be read before the "cacerts" file in the same directory. Keep in mind that as long as the "jssecacerts" file exists, the certificates installed in "cacerts" will not be used. This may cause problems for you. If you don't mind importing your CA certificate into the "cacerts" file, then you can authenticate against all of the CA certificates installed.
HTTP[S] Test Script Recorder [was: HTTP Proxy Server ]
The HTTP[S] Test Script Recorder allows JMeter to intercept and record your actions while you browse your web application with your normal browser. JMeter will create test sample objects and store them directly into your test plan as you go [so you can view samples interactively while you make them]. Ensure you read this wiki page to setup correctly JMeter.
To use the recorder, add the HTTP[S] Test Script Recorder element. Right-click on the Test Plan element to get the Add menu: [ ].
The recorder is implemented as an HTTP[S] proxy server. You need to set up your browser use the proxy for all HTTP and HTTPS requests.
Do not use JMeter as the proxy for any other request types - FTP, etc. - as JMeter cannot handle them.
Ideally use private browsing mode when recording the session. This should ensure that the browser starts with no stored cookies, and prevents certain changes from being saved. For example, Firefox does not allow certificate overrides to be saved permanently.
HTTPS recording and certificates
HTTPS connections use certificates to authenticate the connection between the browser and the web server. When connecting via HTTPS, the server presents the certificate to the browser. To authenticate the certificate, the browser checks that the server certificate is signed by a Certificate Authority [CA] that is linked to one of its in-built root CAs.
Browsers also check that the certificate is for the correct host or domain, and that it is valid and not expired.
If any of the browser checks fail, it will prompt the user who can then decide whether to allow the connection to proceed.
JMeter needs to use its own certificate to enable it to intercept the HTTPS connection from the browser. Effectively JMeter has to pretend to be the target server.
JMeter will generate its own certificate[s]. These are generated with a validity period defined by the property proxy.cert.validity, default 7 days, and random passwords. If JMeter detects that it is running under Java 8 or later, it will generate certificates for each target server as necessary [dynamic mode] unless the following property is defined: proxy.cert.dynamic_keys=false. When using dynamic mode, the certificate will be for the correct host name, and will be signed by a JMeter-generated CA certificate. By default, this CA certificate won't be trusted by the browser, however it can be installed as a trusted certificate. Once this is done, the generated server certificates will be accepted by the browser. This has the advantage that even embedded HTTPS resources can be intercepted, and there is no need to override the browser checks for each new server.
Browsers don't prompt for embedded resources. So with earlier versions, embedded resources would only be downloaded for servers that were already 'known' to the browser
Unless a keystore is provided [and you define the property proxy.cert.alias], JMeter needs to use the keytool application to create the keystore entries. JMeter includes code to check that keytool is available by looking in various standard places. If JMeter is unable to find the keytool application, it will report an error. If necessary, the system property keytool.directory can be used to tell JMeter where to find keytool. This should be defined in the file system.properties.
The JMeter certificates are generated [if necessary] when the Start button is pressed.
Certificate generation can take some while, during which time the GUI will be unresponsive.
The cursor is changed to an hour-glass whilst this is happening. When certificate generation is complete, the GUI will display a pop-up dialogue containing the details of the certificate for the root CA. This certificate needs to be installed by the browser in order for it to accept the host certificates generated by JMeter; see for details.
If necessary, you can force JMeter to regenerate the keystore [and the exported certificates - ApacheJMeterTemporaryRootCA[.usr|.crt]] by deleting the keystore file proxyserver.jks from the JMeter directory.
This certificate is not one of the certificates that browsers normally trust, and will not be for the correct host. As a consequence:
- The browser should display a dialogue asking if you want to accept the certificate or not. For example: httpclient4.retrycount=3 8 You will need to accept the certificate in order to allow the JMeter Proxy to intercept the SSL traffic in order to record it. However, do not accept this certificate permanently; it should only be accepted temporarily. Browsers only prompt this dialogue for the certificate of the main URL, not for the resources loaded in the page, such as images, CSS or JavaScript files hosted on a secured external CDN. If you have such resources [gmail has for example], you'll have to first browse manually to these other domains in order to accept JMeter's certificate for them. Check in jmeter.log for secure domains that you need to register certificate for.
- If the browser has already registered a validated certificate for this domain, the browser will detect JMeter as a security breach and will refuse to load the page. If so, you have to remove the trusted certificate from your browser's keystore.
Versions of JMeter from 2.10 onwards still support this method, and will continue to do so if you define the following property:proxy.cert.aliasThe following properties can be used to change the certificate that is used:
- proxy.cert.directory - the directory in which to find the certificate [default = JMeter bin/]
- proxy.cert.file - name of the keystore file [default "proxyserver.jks"]
- proxy.cert.keystorepass - keystore password [default "password"] [Ignored if using JMeter certificate]
- proxy.cert.keypassword - certificate key password [default "password"] [Ignored if using JMeter certificate]
- proxy.cert.type - the certificate type [default "JKS"] [Ignored if using JMeter certificate]
- proxy.cert.factory - the factory [default "SunX509"] [Ignored if using JMeter certificate]
- proxy.cert.alias - the alias for the key to be used. If this is defined, JMeter does not attempt to generate its own certificate[s].
- proxy.ssl.protocol - the protocol to be used [default "SSLv3"]
If your browser currently uses a proxy [e.g. a company intranet may route all external requests via a proxy], then you need to before starting JMeter, using the -H and -P. This setting will also be needed when running the generated test plan.
Installing the JMeter CA certificate for HTTPS recording
As mentioned above, when run under Java 8, JMeter can generate certificates for each server. For this to work smoothly, the root CA signing certificate used by JMeter needs to be trusted by the browser. The first time that the recorder is started, it will generate the certificates if necessary. The root CA certificate is exported into a file with the name ApacheJMeterTemporaryRootCA in the current launch directory. When the certificates have been set up, JMeter will show a dialog with the current certificate details. At this point, the certificate can be imported into the browser, as per the instructions below.
Note that once the root CA certificate has been installed as a trusted CA, the browser will trust any certificates signed by it. Until such time as the certificate expires or the certificate is removed from the browser, it will not warn the user that the certificate is being relied upon. So anyone that can get hold of the keystore and password can use the certificate to generate certificates which will be accepted by any browsers that trust the JMeter root CA certificate. For this reason, the password for the keystore and private keys are randomly generated and a short validity period used. The passwords are stored in the local preferences area. Please ensure that only trusted users have access to the host with the keystore.
The popup that displays once you start the Recorder is an informational popup:
Recorder Install Certificate Popup
Just click ok and proceed further.
Installing the certificate in Firefox
Choose the following options:
- Tools / Options
- Advanced / Certificates
- View Certificates
- Authorities
- Import …
- Browse to the JMeter launch directory, and click on the file ApacheJMeterTemporaryRootCA.crt, press Open
- Click View and check that the certificate details agree with the ones displayed by the JMeter Test Script Recorder
- If OK, select "Trust this CA to identify web sites", and press OK
- Close dialogs by pressing OK as necessary
Installing the certificate in Chrome or Internet Explorer
Both Chrome and Internet Explorer use the same trust store for certificates.
- Browse to the JMeter launch directory, and click on the file ApacheJMeterTemporaryRootCA.crt, and open it
- Click on the "Details" tab and check that the certificate details agree with the ones displayed by the JMeter Test Script Recorder
- If OK, go back to the "General" tab, and click on "Install Certificate …" and follow the Wizard prompts
Installing the certificate in Opera
- Tools / Preferences / Advanced / Security
- Manage Certificates …
- Select "Intermediate" tab, click "Import …"
- Browse to the JMeter launch directory, and click on the file ApacheJMeterTemporaryRootCA.usr, and open it
Screenshot of Control-Panel of HTTP[S] Test Script Recorder
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Port
The port that the HTTP[S] Test Script Recorder listens to. 8888 is the default, but you can change it.
Yes
HTTPS Domains
List of domain [or host] names for HTTPS. Use this to pre-generate certificates for all servers you wish to record. For example, *.example.com,*.subdomain.example.com Note that wildcard domains only apply to one level, i.e. abc.subdomain.example.com matches *.subdomain.example.com but not *.example.com
No
Target Controller
The controller where the proxy will store the generated samples. By default, it will look for a Recording Controller and store them there wherever it is.
Yes
Grouping
Whether to group samplers for requests from a single "click" [requests received without significant time separation], and how to represent that grouping in the recording:
- Do not group samplers - store all recorded samplers sequentially, without any grouping.
- Add separators between groups - add a controller named "--" to create a visual separation between the groups. Otherwise the samplers are all stored sequentially.
- Put each group in a new controller - create a new for each group, and store all samplers for that group in it.
- Store 1st sampler of each group only - only the first request in each group will be recorded. The "Follow Redirects" and "Retrieve All Embedded Resources …" flags will be turned on in those samplers.
- Put each group in a new transaction controller - create a new for each group, and store all samplers for that group in it.
The property proxy.pause determines the minimum gap that JMeter needs between requests to treat them as separate "clicks". The default is 5000 [milliseconds] i.e. 5 seconds. If you are using grouping, please ensure that you leave the required gap between clicks.
Yes
Capture HTTP Headers
Should headers be added to the plan? If specified, a Header Manager will be added to each HTTP Sampler. The Proxy server always removes Cookie and Authorization headers from the generated Header Managers. By default it also removes If-Modified-Since and If-None-Match headers. These are used to determine if the browser cache items are up to date; when recording one normally wants to download all the content. To change which additional headers are removed, define the JMeter property proxy.headers.remove as a comma-separated list of headers.
Yes
Add Assertions
Add a blank assertion to each sampler?
Yes
Regex Matching
Use Regex Matching when replacing variables? If checked replacement will use word boundaries, i.e. it will only replace word matching values of variable, not part of a word. A word boundary follows Perl5 definition and is equivalent to \b. More information below in the paragraph about "User Defined Variable replacement".
Yes
Prefix/Transaction name
Add a prefix to sampler name during recording [Prefix mode]. Or replace sampler name by user chosen name [Transaction name]
No
Naming scheme
Select the naming scheme for sampler names during recording. Default is Transaction name
No
Naming format
If Use format string is selected as naming scheme, a freestyle format can be given. Placeholders for the transaction name, scheme, host, port, path and counter can be given by #{name}, #{scheme}, #{host}, #{port}, #{path}, #{url} and #{counter}. A simple format could be "#{name}-#{counter}", which would be equivalent to the numbered default naming scheme. For more complex formatting Java formatting for MessageFormat can be used, as in "#{counter,number,000}: #{name}-#{path}", which would print the counter filled with up to three zeroes. Note that scheme is called protocol in the sampler GUI and host is called domain. Default is an empty string.
No
Counter start value
Can be used to reset the counter to a given value. Note, that the next sample will first increment and then use the value. If the first sampler should start with 1, reset the counter to 0.
No
Create new transaction after request [ms]
Inactivity time between two requests needed to consider them in two separate groups.
No
Type
Which type of sampler to generate [the HTTPClient default or Java]
Yes
Redirect Automatically
Set Redirect Automatically in the generated samplers?
Yes
Follow Redirects
Set Follow Redirects in the generated samplers?
Note: see "Recording and redirects" section below for important information.
Yes
Use Keep-Alive
Set Use Keep-Alive in the generated samplers?
Yes
Retrieve all Embedded Resources
Set Retrieve all Embedded Resources in the generated samplers?
Yes
Content Type filter
Filter the requests based on the content-type - e.g. "text/html [;charset=utf-8 ]". The fields are regular expressions which are checked to see if they are contained in the content-type. [Does not have to match the entire field]. The include filter is checked first, then the exclude filter. Samples which are filtered out will not be stored.
Note: this filtering is applied to the content type of the response
No
Patterns to Include
Regular expressions that are matched against the full URL that is sampled. Allows filtering of requests that are recorded. All requests pass through, but only those that meet the requirements of the Include/Exclude fields are recorded. If both Include and Exclude are left empty, then everything is recorded [which can result in dozens of samples recorded for each page, as images, stylesheets, etc. are recorded].
If there is at least one entry in the Include field, then only requests that match one or more Include patterns are recorded
.
No
Patterns to Exclude
Regular expressions that are matched against the URL that is sampled.
Any requests that match one or more Exclude pattern are not recorded
.
No
Notify Child Listeners of filtered samplers
Notify Child Listeners of filtered samplers
Any response that match one or more Exclude pattern is not delivered to Child Listeners [View Results Tree]
.
No
Start Button
Start the proxy server. JMeter writes the following message to the console once the proxy server has started up and is ready to take requests: "Proxy up and running!".
N/A
Stop Button
Stop the proxy server.
N/A
Restart Button
Stops and restarts the proxy server. This is useful when you change/add/delete an include/exclude filter expression.
N/A
Recording and redirects
During recording, the browser will follow a redirect response and generate an additional request. The Proxy will record both the original request and the redirected request [subject to whatever exclusions are configured]. The generated samples have "Follow Redirects" selected by default, because that is generally better.
Redirects may depend on the original request, so repeating the originally recorded sample may not always work.
Now if JMeter is set to follow the redirect during replay, it will issue the original request, and then replay the redirect request that was recorded. To avoid this duplicate replay, JMeter tries to detect when a sample is the result of a previous redirect. If the current response is a redirect, JMeter will save the redirect URL. When the next request is received, it is compared with the saved redirect URL and if there is a match, JMeter will disable the generated sample. It also adds comments to the redirect chain. This assumes that all the requests in a redirect chain will follow each other without any intervening requests. To disable the redirect detection, set the property proxy.redirect.disabling=false
Includes and Excludes
The include and exclude patterns are treated as regular expressions [using Jakarta ORO]. They will be matched against the host name, port [actual or implied], path and query [if any] of each browser request. If the URL you are browsing is "//localhost/jmeter/index.html?username=xxxx", then the regular expression will be tested against the string: "localhost:80/jmeter/index.html?username=xxxx". Thus, if you want to include all .html files, your regular expression might look like: ".*\.html[\?.*]?" - or ".*\.htmlif you know that there is no query string or you only want html pages without query strings.
If there are any include patterns, then the URL must match at least one of the patterns , otherwise it will not be recorded. If there are any exclude patterns, then the URL must not match any of the patterns , otherwise it will not be recorded. Using a combination of includes and excludes, you should be able to record what you are interested in and skip what you are not.
N.B. the string that is matched by the regular expression must be the same as the whole host+path string. Thus "\.html" will not match localhost:80/index.html
Capturing binary POST data
JMeter is able to capture binary POST data. To configure which content-types are treated as binary, update the JMeter property proxy.binary.types. The default settings are as follows:
httpclient4.retrycount=3
9
Adding timers
It is also possible to have the proxy add timers to the recorded script. To do this, create a timer directly within the HTTP[S] Test Script Recorder component. The proxy will place a copy of this timer into each sample it records, or into the first sample of each group if you're using grouping. This copy will then be scanned for occurrences of variable ${T} in its properties, and any such occurrences will be replaced by the time gap from the previous sampler recorded [in milliseconds].
When you are ready to begin, hit "start".
You will need to edit the proxy settings of your browser to point at the appropriate server and port, where the server is the machine JMeter is running on, and the port # is from the Proxy Control Panel shown above.
Where Do Samples Get Recorded?
JMeter places the recorded samples in the Target Controller you choose. If you choose the default option "Use Recording Controller", they will be stored in the first Recording Controller found in the test object tree [so be sure to add a Recording Controller before you start recording].
If the Proxy does not seem to record any samples, this could be because the browser is not actually using the proxy. To check if this is the case, try stopping the proxy. If the browser still downloads pages, then it was not sending requests via the proxy. Double-check the browser options. If you are trying to record from a server running on the same host, then check that the browser is not set to "Bypass proxy server for local addresses" [this example is from IE7, but there will be similar options for other browsers]. If JMeter does not record browser URLs such as //localhost/ or //127.0.0.1/, try using the non-loopback hostname or IP address, e.g. //myhost/ or //192.168.0.2/.
Handling of HTTP Request Defaults
If the HTTP[S] Test Script Recorder finds enabled directly within the controller where samples are being stored, or directly within any of its parent controllers, the recorded samples will have empty fields for the default values you specified. You may further control this behaviour by placing an HTTP Request Defaults element directly within the HTTP[S] Test Script Recorder, whose non-blank values will override those in the other HTTP Request Defaults. See for more info.
User Defined Variable replacement
Similarly, if the HTTP[S] Test Script Recorder finds [UDV] directly within the controller where samples are being stored, or directly within any of its parent controllers, the recorded samples will have any occurrences of the values of those variables replaced by the corresponding variable. Again, you can place User Defined Variables directly within the HTTP[S] Test Script Recorder to override the values to be replaced. See for more info.
Please note that matching is case-sensitive.
Replacement by Variables: by default, the Proxy server looks for all occurrences of UDV values. If you define the variable WEB with the value www, for example, the string www will be replaced by ${WEB} wherever it is found. To avoid this happening everywhere, set the "Regex Matching" check-box. This tells the proxy server to treat values as Regexes [using the perl5 compatible regex matchers provided by ORO].
If "Regex Matching" is selected every variable will be compiled into a perl compatible regex enclosed in\b[ and ]\b. That way each match will start and end at a word boundary.
Note that the boundary characters are not part of the matching group, e.g. n.* to match name out of You can call me 'name'.
If you don't want your regex to be enclosed with those boundary matchers, you have to enclose your regex within parens, e.g ['.*?'] to match 'name' out of You can call me 'name'.
The variables will be checked in random order. So ensure, that the potential matches don't overlap. Overlapping matchers would be .* [which matches anything] and www [which matches www only]. Non-overlapping matchers would be a+ [matches a sequence of a's] and b+ [matches a sequence of b's].
If you want to match a whole string only, enclose it in [ and $], e.g. [^thus$]. The parens are necessary, since the normally added boundary characters will prevent and$ to match.
If you want to match /images at the start of a string only, use the value [/images]. Jakarta ORO also supports zero-width look-ahead, so one can match /images/…but retain the trailing / in the output by using [/images[?=/]].
Note that the current version of Jakarta ORO does not support look-behind - i.e. [?Look out for overlapping matchers. For example the value .* as a regex in a variable namedregex will partly match a previous replaced variable, which will result in something like${{regex}, which is most probably not the desired result.
If there are any problems interpreting any variables as patterns, these are reported in jmeter.log, so be sure to check this if UDVs are not working as expected.
When you are done recording your test samples, stop the proxy server [hit the "stop" button]. Remember to reset your browser's proxy settings. Now, you may want to sort and re-order the test script, add timers, listeners, a cookie manager, etc.
How can I record the server's responses too?
Just place a listener as a child of the HTTP[S] Test Script Recorder and the responses will be displayed. You can also add a Post-Processor which will save the responses to files.
Associating requests with responses
If you define the property proxy.number.requests=trueJMeter will add a number to each sampler and each response. Note that there may be more responses than samplers if excludes or includes have been used. Responses that have been excluded will have labels enclosed in [ and ], for example [23 /favicon.ico]
Cookie Manager
If the server you are testing against uses cookies, remember to add an to the test plan when you have finished recording it. During recording, the browser handles any cookies, but JMeter needs a Cookie Manager to do the cookie handling during a test run. The JMeter Proxy server passes on all cookies sent by the browser during recording, but does not save them to the test plan because they are likely to change between runs.
Authorization Manager
The HTTP[S] Test Script Recorder grabs "Authentication" header, tries to compute the Auth Policy. If Authorization Manager was added to target controller manually, HTTP[S] Test Script Recorder will find it and add authorization [matching ones will be removed]. Otherwise Authorization Manager will be added to target controller with authorization object. You may have to fix automatically computed values after recording.
Uploading files
Some browsers [e.g. Firefox and Opera] don't include the full name of a file when uploading files. This can cause the JMeter proxy server to fail. One solution is to ensure that any files to be uploaded are in the JMeter working directory, either by copying the files there or by starting JMeter in the directory containing the files.
Recording HTTP Based Non Textual Protocols not natively available in JMeter
You may have to record an HTTP protocol that is not handled by default by JMeter [Custom Binary Protocol, Adobe Flex, Microsoft Silverlight, … ]. Although JMeter does not provide a native proxy implementation to record these protocols, you have the ability to record these protocols by implementing a custom SamplerCreator. This Sampler Creator will translate the binary format into a HTTPSamplerBase subclass that can be added to the JMeter Test Case. For more details see "Extending JMeter".
HTTP Mirror Server
The HTTP Mirror Server is a very simple HTTP server - it simply mirrors the data sent to it. This is useful for checking the content of HTTP requests.
It uses default port 8081.
Screenshot of Control-Panel of HTTP Mirror Server
Parameters
Attribute
Description
Required
Port
Port on which Mirror server listens, defaults to 8081.
Yes
Max Number of threads
If set to a value > 0, number of threads serving requests will be limited to the configured number, if set to a value ≤ 0 a new thread will be created to serve each incoming request. Defaults to 0
No
Max Queue size
Size of queue used for holding tasks before they are executed by Thread Pool, when Thread pool is exceeded, incoming requests will be held in this queue and discarded when this queue is full. This parameter is only used if Max Number of Threads is greater than 0. Defaults to 25
No
Note that you can get more control over the responses by adding an HTTP Header Manager with the following name/value pairs:
Parameters
Attribute
Description
Required
X-Sleep
Time to sleep in ms before sending response
No
X-SetCookie
Cookies to be set on response
No
X-ResponseStatus
Response status, see HTTP Status responses, example 200 OK, 500 Internal Server Error, ….
No
X-ResponseLength
Size of response, this trims the response to the requested size if that is less than the total size
No
X-SetHeaders
Pipe separated list of headers, example: headerA: valueA|headerB: valueB would set headerA to valueA and headerB to valueB.
No
You can also use the following query parameters:
Parameters
Attribute
Description
Required
redirect
Generates a 302 [Temporary Redirect] with the provided location, e.g. ?redirect=/path
No
status
Overrides the default status return, e.g. ?status=404 Not Found
No
v
Verbose flag, writes some details to standard output, e.g. first line and redirect location if specified
No
Property Display
The Property Display shows the values of System or JMeter properties. Values can be changed by entering new text in the Value column.
Screenshot of Control-Panel of Property Display
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
Debug Sampler
The Debug Sampler generates a sample containing the values of all JMeter variables and/or properties.
The values can be seen in the Listener Response Data pane.
Screenshot of Control-Panel of Debug Sampler
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
JMeter Properties
Include JMeter properties?
Yes
JMeter Variables
Include JMeter variables?
Yes
System Properties
Include System properties?
Yes
Debug PostProcessor
The Debug PostProcessor creates a subSample with the details of the previous Sampler properties, JMeter variables, properties and/or System Properties.
The values can be seen in the Listener Response Data pane.
Screenshot of Control-Panel of Debug PostProcessor
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
No
JMeter Properties
Whether to show JMeter properties [default false].
Yes
JMeter Variables
Whether to show JMeter variables [default false].
Yes
Sampler Properties
Whether to show Sampler properties [default true].
Yes
System Properties
Whether to show System properties [default false].
Yes
Test Fragment
Screenshot of Control-Panel of Test Fragment
Parameters
Attribute
Description
Required
Name
Descriptive name for this element that is shown in the tree.
Yes
When using Test Fragment with , ensure you disable the Test Fragment to avoid the execution of Test Fragment itself. This is done by default since JMeter 2.13.
setUp Thread Group
A special type of ThreadGroup that can be utilized to perform Post-Test Actions. The behavior of these threads is exactly like a normal element. The difference is that these type of threads execute after the test has finished executing its regular Thread Groups.

FTP Request

Parameters

HTTP Request

Parameters

Parameters

Define characters per second > 0 to emulate slow connections

httpclient.socket.http.cps=0

httpclient.socket.https.cps=0

JDBC Request

Parameters

Java Request

Parameters

Parameters

Parameters

LDAP Request

Parameters

LDAP Extended Request

Parameters

Parameters

Parameters

Parameters

Parameters

Parameters

Parameters

Parameters

Parameters

Access Log Sampler

[Beta Code]

Parameters

BeanShell Sampler

Parameters

JSR223 Sampler

Parameters

TCP Sampler

Parameters

JMS Publisher

Parameters

JMS Subscriber

Parameters

JMS Point-to-Point

Parameters

JUnit Request

General Guidelines

Parameters

Mail Reader Sampler

Parameters

Flow Control Action [was: Test Action ]

Parameters

SMTP Sampler

Parameters

OS Process Sampler

Parameters

MongoDB Script [DEPRECATED]

Parameters

Bolt Request

Parameters

18.2 Logic Controllers

Simple Controller

Parameters

Loop Controller

Parameters

Once Only Controller

Parameters

Interleave Controller

Parameters

Random Controller

Parameters

Random Order Controller

Parameters

Throughput Controller

Parameters

Runtime Controller

Parameters

If Controller

Parameters

httpclient.socket.http.cps=0

httpclient.socket.https.cps=0

Parameters

Random Variable

Parameters