Vs-1120 Certified Jmeter Tester - Reading - Material

Certified Jmeter Tester
VS-1120
V skills
Certified
Jmeter Tester
www.vskills.in
Proficiency Testing Programme
of
VS-1120
Intelligent Communication Systems India

Limited
JV of DSIIDC ( Govt of NCT Delhi) &

TCIL (Govt of India)
This document describes developing,

executing and managing software tests
using the Jmeter exam tool like FTP
tests, Web tests, Database tests. etc
This document is for beginners and
intermediaries.
Certified - Jmeter Tester

Training Material

Copyright 2014
Cubezoid Solutions Private Limited
Content, design, typesetting and published by Cubezoid Solutions Private Limited,

info@cubezoid.com
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License
is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the specific language governing
permissions and limitations under the License.
All rights reserved

This book is provided on the condition that it shall not by way of trade or otherwise, be lent,
resold, hired out or otherwise circulated without the publishers prior consent in any form of
binding or cover other than in which it is published and without a similar condition including this
condition being imposed on the subsequent purchaser and without limiting the rights under the
copyright reserved above, no part of this publication, may be reproduced, stored in or introduced
into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying , recording or otherwise) without the prior permission of the copyright owner and
publisher of the book
Disclaimer:
Due care and diligence has been taken while editing and printing this book. Neither the Author, publisher nor the printer of the
book holds any responsibility for any mistake that may have crept in inadvertently. Cubezoid Solutions Private Limited the
publishers, will be free from any liability for damages and loss of any nature arising out or related to the content. All disputes
are subject to the jurisdiction of the competent courts in Delhi.
www.vskills.in
Page 2
TABLE OF CONTENTS
1. Introduction............................................................................................................................... 7
1.1. History................................................................................................................................................................7
1.2. The Future .........................................................................................................................................................7
2. Getting Started .......................................................................................................................... 8

2.1. Requirements .....................................................................................................................................................9
2.2. Optional .............................................................................................................................................................9
2.3. Installation ........................................................................................................................................................10
2.4. Running JMeter ................................................................................................................................................11
2.5. Configuring JMeter ...........................................................................................................................................18
3. Building a Test Plan................................................................................................................ 20

3.1. Adding and Removing Elements ......................................................................................................................20
3.2. Loading and Saving Elements ...........................................................................................................................20
3.3. Configuring Tree Elements ..............................................................................................................................20
3.4. Saving the Test Plan .........................................................................................................................................20
3.5. Running a Test Plan .........................................................................................................................................21
3.6. Error reporting .................................................................................................................................................22
4. Elements of a Test Plan .......................................................................................................... 23

4.1. ThreadGroup ...................................................................................................................................................23
4.2. Controllers........................................................................................................................................................24
4.3. Listeners ...........................................................................................................................................................26
4.4. Timers..............................................................................................................................................................26
4.5. Assertions .........................................................................................................................................................27
4.6. Configuration Elements ....................................................................................................................................27
4.7. Pre-Processor Elements....................................................................................................................................28
4.8. Post-Processor Elements ..................................................................................................................................28
4.9. Execution order................................................................................................................................................28
4.10. Scoping Rules .................................................................................................................................................29
4.11. Properties and Variables.................................................................................................................................31
4.12. Using Variables to parameterise tests..............................................................................................................31
5. Building a Web Test Plan....................................................................................................... 33

5.1. Adding Users....................................................................................................................................................33
5.2. Adding Default HTTP Request Properties ......................................................................................................34
5.3. Adding Cookie Support....................................................................................................................................36
www.vskills.in
Page 3

5.4. Adding HTTP Requests...................................................................................................................................36
5.5. Adding a Listener to View Store the Test Results .............................................................................................37
5.6. Logging in to a web-site.....................................................................................................................................38
6. Building an Advanced Web Test Plan .................................................................................. 40

6.1. Handling User Sessions With URL Rewriting ..................................................................................................40
6.2. Using a Header Manager ..................................................................................................................................40
7. Building a Database Test Plan ............................................................................................... 42

7.1. Adding Users....................................................................................................................................................42
7.2. Adding JDBC Requests ....................................................................................................................................43
7.3. Adding a Listener to View/Store the Test Results.............................................................................................46
8. Building an FTP Test Plan ..................................................................................................... 47

8.1. Adding Users....................................................................................................................................................47
8.2. Adding Default FTP Request Properties ..........................................................................................................48
8.3. Adding FTP Requests.......................................................................................................................................49
9. Building an LDAP Test Plan.................................................................................................. 52

9.1. Adding Users....................................................................................................................................................52
9.2. Adding Login Config Element..........................................................................................................................52
9.3. Adding LDAP Request Defaults.......................................................................................................................53
9.4. Adding LDAP Requests ...................................................................................................................................53
9.6. Building an Extended LDAP Test Plan............................................................................................................56
9.7. Adding Users....................................................................................................................................................57
9.8. Adding LDAP Extended Request Defaults.......................................................................................................58
9.9. Adding LDAP Requests ...................................................................................................................................58
9.10. Adding a Listener to View/Store the Test Results...........................................................................................65
10. Building a WebService Test Plan ........................................................................................ 66

10.1. Adding Users..................................................................................................................................................66
10.2. Adding WebService Requests.........................................................................................................................67
11. Building a JMS Point-to-Point Test Plan............................................................................ 70

11.1. Adding a Thread Group .................................................................................................................................70
11.2. Adding JMS Point-to-Point Sampler ...............................................................................................................71
11.3. Adding a Listener to View Store the Test Results ...........................................................................................71
12. Building a JMS Topic Test Plan .......................................................................................... 73

www.vskills.in
Page 4

12.1. Adding Users..................................................................................................................................................73
12.2. Adding JMS Subscriber and Publisher ...........................................................................................................74
12.3. Adding a Listener to View Store the Test Results ...........................................................................................76
13. Building a Monitor Test Plan............................................................................................... 78

13.1. Adding A Server .............................................................................................................................................78
13.2. HTTP Auth Manager.....................................................................................................................................78
13.3. Adding HTTP Request ..................................................................................................................................79
13.4. Adding Constant Timer..................................................................................................................................79
13.5. Adding a Listener to Store the Results............................................................................................................79
13.6. Adding Monitor Results..................................................................................................................................79
14. Introduction to listeners ....................................................................................................... 82

14.1. Default Configuration .....................................................................................................................................82
14.2. non-GUI (batch) test runs ...............................................................................................................................85
14.3. Resource usage ...............................................................................................................................................86
14.4. CSV Log format .............................................................................................................................................86
14.5. XML Log format 2.1 ......................................................................................................................................87
14.6. XML Log format 2.2 ......................................................................................................................................89
14.7. Sample Attributes ...........................................................................................................................................89
14.8. Saving response data .......................................................................................................................................89
14.9. Loading (reading) response data .....................................................................................................................89
14.10. Saving Listener GUI data..............................................................................................................................90
15. Remote Testing...................................................................................................................... 91

15.1. Doing it Manually ...........................................................................................................................................93
15.2. Tips ................................................................................................................................................................93
15.3. Using a different port......................................................................................................................................94
15.4. Using a different sample sender......................................................................................................................95
16. Best Practices......................................................................................................................... 97

16.1. Always use latest version of JMeter .................................................................................................................97
16.2. Limit the Number of Threads ........................................................................................................................97
16.3. Where to Put the Cookie Manager.................................................................................................................97
16.4. Where to Put the Authorization Manager ......................................................................................................97
16.5. User variables .................................................................................................................................................98
16.6. Reducing resource requirements ....................................................................................................................98
16.7. BeanShell server .............................................................................................................................................99
16.8. BeanShell scripting .......................................................................................................................................100
www.vskills.in
Page 5

16.9. Developing script functions in BeanShell, Javascript or Jexl etc. ...................................................................101
16.10. Parameterising tests.....................................................................................................................................101
17. Help! My boss wants me to load test our web app! ......................................................... 103
17.1. Questions to ask ...........................................................................................................................................103
17.2. Resources .....................................................................................................................................................103
17.3. Network........................................................................................................................................................103
17.4. Application ...................................................................................................................................................103
17.5. What platform should I use to run the benchmarks/load-tests ?...................................................................104
17.6. Tools ............................................................................................................................................................104
17.7. What other products are there ?...................................................................................................................105
17.8. Why Java ? ...................................................................................................................................................105
18. Functions.............................................................................................................................. 106

18.1. What can functions do..................................................................................................................................107
18.2. Where can functions and variables be used? ................................................................................................108
18.3. How to reference variables and functions .....................................................................................................108
18.4. The Function Helper Dialog ........................................................................................................................109
18.5. Functions ......................................................................................................................................................110
19. Regular Expressions ........................................................................................................... 128

19.1. Overview.......................................................................................................................................................128
19.2. Examples ......................................................................................................................................................128
19.3. Line mode ....................................................................................................................................................130
19.4. Meta characters.............................................................................................................................................130
20. Hints and Tips ..................................................................................................................... 132

20.1. Enabling Debug logging ................................................................................................................................132
20.2. Searching ......................................................................................................................................................132
www.vskills.in
Page 6
1. INTRODUCTION
Apache JMeter is a 100% pure Java desktop application designed to load test client/server software
(such as a web application). It may be used to test performance both on static and dynamic
resources such as static files, Java Servlets, CGI scripts, Java objects, databases, FTP servers, and
more. JMeter can be used to simulate a heavy load on a server, network or object to test its
strength or to analyze overall performance under different load types.
Additionally, JMeter can help you regression test your application by letting you create test scripts
with assertions to validate that your application is returning the results you expect. For maximum
flexibility, JMeter lets you create these assertions using regular expressions.
But please note that JMeter is not a browser, it works at protocol level.
1.1. History
Stefano Mazzocchi of the Apache Software Foundation was the original developer of JMeter. He
wrote it primarily to test the performance of Apache JServ (a project that has since been replaced
by the Apache Tomcat project). We redesigned JMeter to enhance the GUI and to add functionaltesting capabilities.
JMeter became a Top Level Apache project in November 2011, which means it has a Project
Management Commitee and a dedicated website.
1.2. The Future

We hope to see JMeter's capabilities rapidly expand as developers take advantage of its pluggable
architecture.
The primary goal of further developments will be:
Addition of Websocket protocol
Addition of FTPS and SFTP protocols
Enhancements to Webservices protocols (SOAP Attachments)
Enhancements to JMS protocol implementation
www.vskills.in
Page 7
2. GETTING STARTED
The easiest way to begin using JMeter is to first download the latest production release and install
it. The release contains all of the files you need to build and run most types of tests, e.g. Web
(HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit and more.
If you want to perform JDBC testing, then you will, of course, need the appropriate JDBC driver
from your vendor. JMeter does not come with any JDBC drivers.
JMeter includes the JMS API jar, but does not include a JMS client implementation. If you want to
run JMS tests, you will need to download the appropriate jars from the JMS provider.
Next, start JMeter and go through the Building a Test Plan section of the User Guide to familiarize
yourself with JMeter basics (for example, adding and removing elements).
Finally, go through the appropriate section on how to build a specific type of Test Plan. For
example, if you are interested in testing a Web application, then see the section Building a Web
Test Plan. The other specific Test Plan sections are:
Advanced Web Test Plan
JDBC
FTP
JMS Point-to-Point
JMS Topic
LDAP
LDAP Extended
WebServices (SOAP)
Once you are comfortable with building and running JMeter Test Plans, you can look into the
various configuration elements (timers, listeners, assertions, and others) which give you more
control over your Test Plans.
Create Test Plan from Template

You have the ability to create a new Test Plan from existing template.
To do so you use the menu File > Templates...
Templates or Templates icon:
Templates icon item
A popup appears, you can then choose a template among the list:
www.vskills.in
Page 8
Templates popup
A documentation for each template explains what to do once test plan is created from template.
2.1. Requirements
JMeter requires your computing environment meets some minimum requirements.
Java Version
JMeter requires a fully compliant JVM 6 or higher.
Because JMeter uses only standard Java APIs, please do not file bug reports if your JRE fails to run
JMeter because of JRE implementation issues.
Operating Systems
JMeter is a 100% Java application and should run correctly on any system that has a compliant Java
implementation.
Operating systems tested with JMeter can be view on this page on JMeter wiki.
Even if your OS is not listed on the wiki page, JMeter should run on it provided that the JVM is
compliant.
2.2. Optional
If you plan on doing JMeter development, then you will need one or more optional packages listed
below.
Java Compiler
If you want to build the JMeter source or develop JMeter plugins, then you will need a fully
compliant JDK 6 or higher.
SAX XML Parser

JMeter comes with Apache's Xerces XML parser . You have the option of telling JMeter to use a
different XML parser. To do so, include the classes for the third-party parser in JMeter's classpath
, and update the jmeter.properties file with the full classname of the parser implementation.
www.vskills.in
Page 9

Email Support
JMeter has extensive Email capabilities. It can send email based on test results, and has a
POP3(S)/IMAP(S) sampler. It also has an SMTP(S) sampler.
SSL Encryption
To test a web server using SSL encryption (HTTPS), JMeter requires that an implementation of
SSL be provided, as is the case with Sun Java 1.4 and above. If your version of Java does not
include SSL support, then it is possible to add an external implementation. Include the necessary
encryption packages in JMeter's classpath . Also, update system.properties to register the SSL
Provider.
JMeter HTTP defaults to protocol level TLS. This can be changed by editing the JMeter property
https.default.protocol in jmeter.properties or user.properties.
The JMeter HTTP samplers are configured to accept all certificates, whether trusted or not,
regardless of validity periods, etc. This is to allow the maximum flexibility in testing servers.
If the server requires a client certificate, this can be provided.
There is also the SSL Manager , for greater control of certificates.
The JMeter proxy server (see below) supports recording HTTPS (SSL)
The SMTP sampler can optionally use a local trust store or trust all certificates.
JDBC Driver
You will need to add your database vendor's JDBC driver to the classpath if you want to do JDBC
testing. Make sure the file is a jar file, not a zip.
JMS client
JMeter now includes the JMS API from Apache Geronimo, so you just need to add the
appropriate JMS Client implementation jar(s) from the JMS provider. Please refer to their
documentation for details. There may also be some information on the JMeter Wiki .
Libraries for ActiveMQ JMS

At the time of writing, the current version of ActiveMQ is 5.3.2. You will need to add the jar
activemq-all-5.3.2.jar to your classpath, e.g. by storing it in the lib/ directory.
Alternatively, add the jar activemq-core-5.3.2.jar to the classpath; this requires the
javax/management/j2ee classes which can be found in the Apache Geronimo jar geronimo-j2eemanagement_1.0_spec-1.0.jar. The other required jars (such as commons-logging) are already
included with JMeter.
2.3. Installation
We recommend that most users run the latest release .
www.vskills.in
Page 10

To install a release build, simply unzip the zip/tar file into the directory where you want JMeter to
be installed. Provided that you have a JRE/JDK correctly installed and the JAVA_HOME
environment variable set, there is nothing more for you to do.
Note: there can be problems (especially with client-server mode) if the directory path contains any
spaces.
The installation directory structure should look something like this (where X.Y is version number):
apache-jmeter-X.Y
apache-jmeter-X.Y/bin
apache-jmeter-X.Y/docs
apache-jmeter-X.Y/extras
apache-jmeter-X.Y/lib/
apache-jmeter-X.Y/lib/ext
apache-jmeter-X.Y/lib/junit
apache-jmeter-X.Y/licenses
apache-jmeter-X.Y/printable_docs
You can rename the parent directory (i.e. apache-jmeter-X.Y) if you want, but do not change any
of the sub-directory names.
2.4. Running JMeter

To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in
the bin directory. After a short time, the JMeter GUI should appear.
There are some additional scripts in the bin directory that you may find useful. Windows script
files (the .CMD files require Win2K or later):
jmeter.bat - run JMeter (in GUI mode by default)
jmeter-n.cmd - drop a JMX file on this to run a non-GUI test
jmeter-n-r.cmd - drop a JMX file on this to run a non-GUI test remotely
jmeter-t.cmd - drop a JMX file on this to load it in GUI mode
jmeter-server.bat - start JMeter in server mode
mirror-server.cmd - runs the JMeter Mirror Server in non-GUI mode
shutdown.cmd - Run the Shutdown client to stop a non-GUI instance gracefully
stoptest.cmd - Run the Shutdown client to stop a non-GUI instance abruptly
Note: the special name LAST can be used with jmeter-n.cmd, jmeter-t.cmd and jmeter-n-r.cmd
and means the last test plan that was run interactively.
The environment variable JVM_ARGS can be used to override JVM settings in the jmeter.bat
script. For example:
set JVM_ARGS="-Xms1024m -Xmx1024m -Dpropname=propvalue"
jmeter -t test.jmx ...
www.vskills.in
Page 11

Un*x script files; should work on most Linux/Unix systems:
jmeter - run JMeter (in GUI mode by default). Defines some JVM settings which may not work
for all JVMs.
jmeter-server - start JMeter in server mode (calls jmeter script with appropriate parameters)
jmeter.sh - very basic JMeter script with no JVM options specified.
mirror-server.sh - runs the JMeter Mirror Server in non-GUI mode
shutdown.sh - Run the Shutdown client to stop a non-GUI instance gracefully
stoptest.sh - Run the Shutdown client to stop a non-GUI instance abruptly
It may be necessary to edit the jmeter shell script if some of the JVM options are not supported by
the JVM you are using. The JVM_ARGS environment variable can be used to override or set
additional JVM options, for example:
JVM_ARGS="-Xms1024m -Xmx1024m" jmeter -t test.jmx [etc.]
will override the HEAP settings in the script.
JMeter's Classpath
JMeter automatically finds classes from jars in the following directories:
JMETER_HOME/lib - used for utility jars
JMETER_HOME/lib/ext - used for JMeter components and plugins
If you have developed new JMeter components, then you should jar them and copy the jar into
JMeter's lib/ext directory. JMeter will automatically find JMeter components in any jars found here.
Do not use lib/ext for utility jars or dependency jars used by the plugins; it is only intended for
JMeter components and plugins.
If you don't want to put JMeter plugin jars in the lib/ext
lib/e directory, then define the property
search_paths in jmeter.properties.
Utility and dependency jars (libraries etc) can be placed in the lib directory.
If you don't want to put such jars in the lib directory, then define the property user.classpath or
plugin_dependency_paths in jmeter.properties. See below for an explanation of the differences.
Other jars (such as JDBC, JMS implementations and any other support libraries needed by the
JMeter code) should be placed in the lib directory - not the lib/ext directory, or added to
user.classpath .
Note: JMeter will only find .jar files, not .zip.

You can also install utility Jar files in $JAVA_HOME/jre/lib/ext, or you can set the property
user.classpath in jmeter.properties
www.vskills.in
Page 12

Note
Note that setting the CLASSPATH environment variable will have no effect. This is because
JMeter is started with "java -jar", and the java command silently ignores the CLASSPATH variable,
and the -classpath/-cp options when -jar is used. [This occurs with all Java programs, not just
JMeter.]
Using a HTTP(S) Test Script Recorder
If you are testing from behind a firewall/proxy server, you may need to provide JMeter with the
firewall/proxy server hostname and port number. To do so, run the jmeter[.bat] file from a
command line with the following parameters:
-H [proxy server hostname or ip address]
-P [proxy server port]
-N [nonproxy hosts] (e.g. *.apache.org|localhost)
-u [username for proxy authentication - if required]
-a [password for proxy authentication - if required]
Example : jmeter -H my.proxy.server -P 8000 -u username -a password -N localhost

You can also use --proxyHost, --proxyPort, --username, and --password as parameter names
Parameters provided on a command-line may be visible to other users on the system.
If the proxy host and port are provided, then JMeter sets the following System properties:
http.proxyHost
http.proxyPort
https.proxyHost
https.proxyPort
If a nonproxy host list is provided, then JMeter sets the following System properties:
http.nonProxyHosts
https.nonProxyHosts
So if you don't wish to set both http and https proxies, you can define the relevant properties in
system.properties instead of using the command-line parameters.
Proxy Settings can also be defined in a Test Plan, using either the HTTP Request Defaults
configuration or the HTTP Request sampler elements.
JMeter also has its own in-built Proxy Server, the HTTP(S) Test Script Recorder . This is
only used for recording HTTP or HTTPS browser sessions. This is not to be confused
with the proxy settings described above, which is used when JMeter makes HTTP or
HTTPS requests itself.
www.vskills.in
Page 13

NonNon-GUI Mode (Command Line mode)
For non-interactive testing, you may choose to run JMeter without the GUI. To do so, use the
following command options:
-n This specifies JMeter is to run in non-gui mode
-t [name of JMX file that contains the Test Plan].
-l [name of JTL file to log sample results to].
-j [name of JMeter run log file].
-r Run the test in the servers specified by the JMeter property "remote_hosts"
-R [list of remote servers] Run the test in the specified remote servers
The script also lets you specify the optional firewall/proxy server information:
Example : jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

If the property jmeterengine.stopfail.system.exit is set to true (default is false), then JMeter will
invoke System.exit(1) if it cannot stop all threads. Normally this is not necessary.
Server
Server Mode
For distributed testing , run JMeter in server mode on the remote node(s), and then control the
server(s) from the GUI. You can also use non-GUI mode to run remote tests. To start the
server(s), run jmeter-server[.bat] on each server host.
The script also lets you specify the optional firewall/proxy server information:
Example : jmeter-server -H my.proxy.server -P 8000

If you want the server to exit after a single test has been run, then define the JMeter property
server.exitaftertest=true.
To run the test from the client in non-GUI mode, use the following command:
jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-Z]
where:
-G is used to define JMeter properties to be set in the servers
-X means exit the servers at the end of the test
-Rserver1,server2 - can be used instead of -r to provide a list of servers to start
Overrides remote_hosts, but does not define the property.
If the property jmeterengine.remote.system.exit is set to true (default is false), then JMeter will
invoke System.exit(0) after stopping RMI at the end of a test. Normally this is not necessary.
www.vskills.in
Page 14

Overriding Properties Via The Command Line
Java system properties, JMeter properties, and logging properties can be overridden directly on the
command line (instead of modifying jmeter.properties). To do so, use the following options:
-D[prop_name]=[value] - defines a java system property value.
-J[prop name]=[value] - defines a local JMeter property.
-G[prop name]=[value] - defines a JMeter property to be sent to all remote servers.
-G[propertyfile] - defines a file containing JMeter properties to be sent to all remote
servers.
-L[category]=[priority] - overrides a logging setting, setting a particular category to the given
priority level.
The -L flag can also be used without the category name to set the root logging level.
Examples :
jmeter -Duser.dir=/home/mstover/jmeter_stuff \
-Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG
jmeter -LDEBUG
N.B.
The command line properties are processed early in startup, but after the logging system has been
set up. Attempts to use the -J flag to update log_level or log_file properties will have no effect.
Logging and error messages

JMeter does not generally use pop-up dialog boxes for errors, as these would interfere with
running tests. Nor does it report any error for a mis-spelt variable or function; instead the
reference is just used as is. See Functions and Variables for more information .
If JMeter detects an error during a test, a message will be written to the log file. The log file name is
defined in the jmeter.properties file (or using the -j option, see below). It defaults to jmeter.log ,
and will be found in the directory from which JMeter was launched.
The menu Options > Log Viewer displays the log file in a bottom pane on main JMeter window.
In the GUI mode, the number of error/fatal messages logged in the log file is displayed at top-right.
Error/fatal counter
The command-line option -j jmeterlogfile allow to process after the initial properties file is read,
and before any further properties are processed. It therefore allows the default of jmeter.log to be
overridden. The jmeter scripts that take a test plan name as a parameter (e.g. jmeter-n.cmd) have
www.vskills.in
Page 15

been updated to define the log file using the test plan name, e.g. for the test plan Test27.jmx the
log file is set to Test27.log.
When running on Windows, the file may appear as just jmeter unless you have set Windows to
show file extensions. [Which you should do anyway, to make it easier to detect viruses and other
nasties that pretend to be text files...]
As well as recording errors, the jmeter.log file records some information about the test run. For
example:
10/17/2003 12:19:20 PM INFO - jmeter.JMeter: Version 1.9.20031002
10/17/2003 12:19:45 PM INFO
- jmeter.gui.action.Load: Loading file:
c:\mytestfiles\BSH.jmx
10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Running the test!
10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Starting 1 threads
for group BSH. Ramp up = 1.
10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Continue on
error
10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 started
10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 is done
10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Test has ended
The log file can be helpful in determining the cause of an error, as JMeter does not interrupt a test
to display an error dialogue.
Full list of commandcommand-line options

Invoking JMeter as "jmeter -?" will print a list of all the command-line options. These are shown
below.
-h, --help
print usage information and exit
-v, --version
print the version information and exit
-p, --propfile {argument}
the jmeter property file to use
-q, --addprop {argument}
additional property file(s)
-t, --testfile {argument}
the jmeter test(.jmx) file to run
-j, --jmeterlogfile {argument}
the jmeter log file
-l, --logfile {argument}
the file to log samples to
-n, --nongui
run JMeter in nongui mode
-s, --server
run the JMeter server
www.vskills.in
Page 16

-H, --proxyHost {argument}
Set a proxy server for JMeter to use
-P, --proxyPort {argument}
Set proxy server port for JMeter to use
-u, --username {argument}
Set username for proxy server that JMeter is to use
-a, --password {argument}
Set password for proxy server that JMeter is to use
-J, --jmeterproperty {argument}={value}
Define additional JMeter properties
-G, --globalproperty (argument)[=(value)]
Define Global properties (sent to servers)
e.g. -Gport=123
or -Gglobal.properties
-D, --systemproperty {argument}={value}
Define additional System properties
-S, --systemPropertyFile {filename}
a property file to be added as System properties
-L, --loglevel {argument}={value}
Define loglevel: [category=]level
e.g. jorphan=INFO or jmeter.util=DEBUG
-r, --runremote (non-GUI only)
Start remote servers (as defined by the jmeter property remote_hosts)
-R, --remotestart server1,... (non-GUI only)
Start these remote servers (overrides remote_hosts)
-d, --homedir {argument}
the jmeter home directory to use
-X, --remoteexit
Exit the remote servers at end of test (non-GUI)
Note: the JMeter log file name is formatted as a SimpleDateFormat (applied to the current date) if
it contains paired single-quotes, .e.g. 'jmeter_'yyyyMMddHHmmss'.log'
If the special name LAST is used for the -t, -j or -l flags, then JMeter takes that to mean the last test
plan that was run in interactive mode.
nonnon-GUI shutdown
Prior to version 2.5.1, JMeter invoked System.exit() when a non-GUI test completed. This caused
problems for applications that invoke JMeter directly, so JMeter no longer invokes System.exit()
for a normal test completion. [Some fatal errors may still invoke System.exit()] JMeter will exit all
the non-daemon threads it starts, but it is possible that some non-daemon threads may still remain;
these will prevent the JVM from exitting. To detect this situation, JMeter starts a new daemon
thread just before it exits. This daemon thread waits a short while; if it returns from the wait, then
clearly the JVM has not been able to exit, and the thread prints a message to say why.
The property jmeter.exit.check.pause can be used to override the default pause of 2000ms (2secs).
If set to 0, then JMeter does not start the daemon thread.
www.vskills.in
Page 17

2.5. Configuring JMeter
If you wish to modify the properties with which JMeter runs you need to either modify the
jmeter.properties in the /bin directory or create your own copy of the jmeter.properties and specify
it in the command line.
Note: You can define additional JMeter properties in the file defined by the JMeter property
user.properties which has the default value user.properties . The file will be automatically loaded if
it is found in the current directory or if it is found in the JMeter bin directory. Similarly,
system.properties is used to update system properties.
Parameters
Attribute
Description
Required
You can specify the class for your SSL implementation if you
No
ssl.provider
don't want to use the built-in Java implementation.
You can specify an implementation as your XML parser. The
No
xml.parser
default value is: org.apache.xerces.parsers.SAXParser
Comma-delimited list of remote JMeter hosts (or host:port if
required). If you are running JMeter in a distributed
remote_hosts
environment, list the machines where you have JMeter remote No
servers running. This will allow you to control those servers
from this machine's GUI
A list of components you do not want to see in JMeter's menus.
As JMeter has more and more components added, you may
wish to customize your JMeter to show only those components
not_in_menu
No
you are interested in. You may list their classname or their class
label (the string that appears in JMeter's UI) here, and they will
no longer appear in the menus.
List of paths (separated by ;) that JMeter will search for JMeter
plugin classes, for example additional samplers. A path item
can either be a jar file or a directory. Any jar file in such a
No
search_paths
directory will be automatically included in search_paths, jar
files in sub directories are ignored. The given value is in
addition to any jars found in the lib/ext directory.
List of paths that JMeter will search for utility and plugin
dependency classes. Use your platform path separator to
separate multiple paths. A path item can either be a jar file or a
directory. Any jar file in such a directory will be automatically
user.classpath
included in user.classpath, jar files in sub directories are No
ignored. The given value is in addition to any jars found in the
lib directory. All entries will be added to the class path of the
system class loader and also to the path of the JMeter internal
loader.
plugin_dependenc List of paths (separated by ;) that JMeter will search for utility
No
y_paths
and plugin dependency classes. A path item can either be a jar
www.vskills.in
Page 18

Attribute
Description
Required
file or a directory. Any jar file in such a directory will be
automatically included in plugin_dependency_paths, jar files in
sub directories are ignored. The given value is in addition to
any jars found in the lib directory or given by the user.classpath
property. All entries will be added to the path of the JMeter
internal loader only. For plugin dependencies using
plugin_dependency_paths should be preferred over
user.classpath.
Name of file containing additional JMeter properties. These
user.properties
are added after the initial property file, but before the -q and -J No
options are processed.
Name of file containing additional system properties. These are
system.properties
No
added before the -S and -D options are processed.
The command line options and properties files are processed in the following order:
-p propfile
jmeter.properties (or the file from the -p option) is then loaded
-j logfile
Logging is initialized
user.properties is loaded
system.properties is loaded
all other command-line options are processed
www.vskills.in
Page 19
3. BUILDING A TEST PLAN

A test plan describes a series of steps JMeter will execute when run. A complete test plan will
consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners,
timers, assertions, and configuration elements.
3.1. Adding and Removing Elements

Adding elements to a test plan can be done by right-clicking on an element in the tree, and
choosing a new element from the "add" list. Alternatively, elements can be loaded from file and
added by choosing the "merge" or "open" option.
To remove an element, make sure the element is selected, right-click on the element, and choose
the "remove" option.
3.2. Loading and Saving Elements

To load an element from file, right click on the existing tree elements to which you want to add the
loaded element, and select the "merge" option. Choose the file where your elements are saved.
JMeter will merge the elements into the tree.
To save tree elements, right click on an element and choose the "Save Selection As ..." option.
JMeter will save the element selected, plus all child elements beneath it. In this way, you can save
test tree fragments and individual elements for later use.
The workbench is not automatically saved with the test plan, but it can be saved separately
as above.
3.3. Configuring Tree Elements

Any element in the test tree will present controls in JMeter's right-hand frame. These controls
allow you to configure the behavior of that particular test element. What can be configured for an
element depends on what type of element it is.
The Test Tree itself can be manipulated by dragging and dropping components around the
test tree.
3.4. Saving the Test Plan

Although it is not required, we recommend that you save the Test Plan to a file before running it.
To save the Test Plan, select "Save" or "Save Test Plan As ..." from the File menu (with the latest
release, it is no longer necessary to select the Test Plan element first).
JMeter allows you to save the entire Test Plan tree or only a portion of it. To save only the
elements located in a particular "branch" of the Test Plan tree, select the Test Plan element
in the tree from which to start the "branch", and then click your right mouse button to
access the "Save Selection As ..." menu item. Alternatively, select the appropriate Test Plan
element and then select "Save Selection As ..." from the Edit menu.
www.vskills.in
Page 20

3.5. Running a Test Plan
To run your test plan, choose "Start" (Control + r) from the "Run" menu item. When JMeter is
running, it shows a small green box at the right hand end of the section just under the menu bar.
You can also check the "Run" menu. If "Start" is disabled, and "Stop" is enabled, then JMeter is
running your test plan (or, at least, it thinks it is).
The numbers to the left of the green box are the number of active threads / total number of
threads. These only apply to a locally run test; they do not include any threads started on remote
systems when using client-server mode.
Stopping a Test
There are two types of stop command available from the menu:
Stop (Control + '.') - stops the threads immediately if possible. In Versions of JMeter after 2.3.2,
many samplers are now Interruptible which means that active samples can be terminated early.
The stop command will check that all threads have stopped within the default timeout, which is
5000
ms
=
5
seconds.
[This
can be
changed
using
the JMeter
propertyjmeterengine.threadstop.wait ] If the threads have not stopped, then a message is
displayed. The Stop command can be retried, but if it fails, then it is necessary to exit JMeter to
clean up.
Shutdown (Control + ',')- requests the threads to stop at the end of any current work. Will not
interrupt any active samples. The modal shutdown dialog box will remain active until all threads
have stopped.
Versions of JMeter after 2.3.2 allow a Stop to be initiated if Shutdown is taking too long. Close the
Shutdown dialog box and select Run/Stop, or just press Control + '.'.
When running JMeter in non-GUI mode, there is no Menu, and JMeter does not react to
keystrokes such as Control + '.'. So in versions after 2.3.2, JMeter non-GUI mode will listen for
commands on a specific port (default 4445, see the JMeter property jmeterengine.nongui.port ). In
versions after 2.4, JMeter supports automatic choice of an alternate port if the default port is being
used (for example by another JMeter instance). In this case, JMeter will try the next higher port,
continuing until it reaches the JMeter property jmeterengine.nongui.maxport) which defaults to
4455. If maxport is less than or equal to port , port scanning will not take place. Note that JMeter
2.4 and earlier did not set up the listener for non-GUI clients, only non-GUI standalone tests; this
has been fixed.
The chosen port is displayed in the console window.
The commands currently supported are:
Shutdown - graceful shutdown
StopTestNow - immediate shutdown
www.vskills.in
Page 21

These commands can be sent by using the shutdown[.cmd|.sh] orstoptest[.cmd|.sh] script
respectively. The scripts are to be found in the JMeter bin directory. The commands will only be
accepted if the script is run from the same host.
3.6. Error reporting

reporting
JMeter reports warnings and errors to the jmeter.log file, as well as some information on the test
run itself. JMeter shows at the right hand end of its window, the number of warnings/errors found
in jmeter.log file next to the warning icon. Click on the warning icon to show the jmeter.log file at
the bottom of JMeter's window. Just occasionally there may be some errors that JMeter is unable to
trap and log; these will appear on the command console. If a test is not behaving as you expect,
please check the log file in case any errors have been reported (e.g. perhaps a syntax error in a
function call).
Sampling errors (e.g. HTTP 404 - file not found) are not normally reported in the log file. Instead
these are stored as attributes of the sample result. The status of a sample result can be seen in the
various different Listeners.
www.vskills.in
Page 22
4. ELEMENTS OF A TEST PLAN

PLAN
The Test Plan object has a checkbox called "Functional Testing". If selected, it will cause JMeter to
record the data returned from the server for each sample. If you have selected a file in your test
listeners, this data will be written to file. This can be useful if you are doing a small run to ensure
that JMeter is configured correctly, and that your server is returning the expected results. The
consequence is that the file will grow huge quickly, and JMeter's performance will suffer. This
option should be off if you are doing stress-testing (it is off by default).
If you are not recording the data to file, this option makes no difference.
You can also use the Configuration button on a listener to decide what fields to save.
4.1. ThreadGroup
Thread group elements are the beginning points of any test plan. All controllers and samplers must
be under a thread group. Other elements, e.g. Listeners, may be placed directly under the test
plan, in which case they will apply to all the thread groups. As the name implies, the thread group
element controls the number of threads JMeter will use to execute your test. The controls for a
thread group allow you to:
Set the number of threads
Set the ramp-up period
Set the number of times to execute the test
Each thread will execute the test plan in its entirety and completely independently of other test
threads. Multiple threads are used to simulate concurrent connections to your server application.
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads
chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100
seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the
previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then
each successive thread will be delayed by 4 seconds.
Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short
enough that the last threads start running before the first ones finish (unless one wants that to
happen).
Start with Ramp-up = number of threads and adjust up or down as needed.
By default, the thread group is configured to loop once through its elements.
Version 1.9 introduces a test run scheduler . Click the checkbox at the bottom of the Thread
Group panel to reveal extra fields in which you can enter the start and end times of the run. When
the test is started, JMeter will wait if necessary until the start-time has been reached. At the end of
each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise
the test is allowed to continue until the iteration limit is reached.
www.vskills.in
Page 23

Alternatively, one can use the relative delay and duration fields. Note that delay overrides starttime, and duration over-rides end-time.
4.2. Controllers
JMeter has two types of Controllers: Samplers and Logical Controllers. These drive the processing
of a test.
Samplers tell JMeter to send requests to a server. For example, add an HTTP Request Sampler if
you want JMeter to send an HTTP request. You can also customize a request by adding one or
more Configuration Elements to a Sampler. For more information, see Samplers .
Logical Controllers let you customize the logic that JMeter uses to decide when to send requests.
For example, you can add an Interleave Logic Controller to alternate between two HTTP Request
Samplers. For more information, see Logical Controllers .
Samplers
Samplers tell JMeter to send requests to a server and wait for a response. They are processed in
the order they appear in the tree. Controllers can be used to modify the number of repetitions of a
sampler.
JMeter samplers include:
FTP Request
HTTP Request
JDBC Request
Java object request
LDAP Request
SOAP/XML-RPC Request
WebService (SOAP) Request
Each sampler has several properties you can set. You can further customize a sampler by adding
one or more Configuration Elements to the Test Plan.
If you are going to send multiple requests of the same type (for example, HTTP Request) to the
same server, consider using a Defaults Configuration Element. Each controller has one or more
Defaults elements (see below).
Remember to add a Listener to your test plan to view and/or store the results of your requests to
disk.
If you are interested in having JMeter perform basic validation on the response of your request,
add an Assertion to the sampler. For example, in stress testing a web application, the server may
return a successful "HTTP Response" code, but the page may have errors on it or may be missing
sections. You could add assertions to check for certain HTML tags, common error strings, and so
on. JMeter lets you create these assertions using regular expressions.
www.vskills.in
Page 24

Logic Controllers
Logic Controllers let you customize the logic that JMeter uses to decide when to send requests.
Logic Controllers can change the order of requests coming from their child elements. They can
modify the requests themselves, cause JMeter to repeat requests, etc.
To understand the effect of Logic Controllers on a test plan, consider the following test tree:
Test Plan
Thread Group
Once Only Controller
Login Request (an HTTP Request )
Load Search Page (HTTP Sampler)
Interleave Controller
Search "A" (HTTP Sampler)
Search "B" (HTTP Sampler)
HTTP default request (Configuration Element)
HTTP default request (Configuration Element)
Cookie Manager (Configuration Element)
The first thing about this test is that the login request will be executed only the first time through.
Subsequent iterations will skip it. This is due to the effects of the Once Only Controller .
After the login, the next Sampler loads the search page (imagine a web application where the user
logs in, and then goes to a search page to do a search). This is just a simple request, not filtered
through any Logic Controller.
After loading the search page, we want to do a search. Actually, we want to do two different
searches. However, we want to re-load the search page itself between each search. We could do
this by having 4 simple HTTP request elements (load search, search "A", load search, search "B").
Instead, we use the Interleave Controller which passes on one child request each time through the
test. It keeps the ordering (ie - it doesn't pass one on at random, but "remembers" its place) of its
child elements. Interleaving 2 child requests may be overkill, but there could easily have been 8, or
20 child requests.
Note the HTTP Request Defaults that belongs to the Interleave Controller. Imagine that "Search
A" and "Search B" share the same PATH info (an HTTP request specification includes domain,
port, method, protocol, path, and arguments, plus other optional items). This makes sense - both
are search requests, hitting the same back-end search engine (a servlet or cgi-script, let's say).
Rather than configure both HTTP Samplers with the same information in their PATH field, we
can abstract that information out to a single Configuration Element. When the Interleave
Controller "passes on" requests from "Search A" or "Search B", it will fill in the blanks with values
from the HTTP default request Configuration Element. So, we leave the PATH field blank for
those requests, and put that information into the Configuration Element. In this case, this is a
minor benefit at best, but it demonstrates the feature.
The next element in the tree is another HTTP default request, this time added to the Thread
Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses this
www.vskills.in
Page 25

Configuration Element exactly as described above. It fills in the blanks of any Request that passes
through. It is extremely useful in web testing to leave the DOMAIN field blank in all your HTTP
Sampler elements, and instead, put that information into an HTTP default request element, added
to the Thread Group. By doing so, you can test your application on a different server simply by
changing one field in your Test Plan. Otherwise, you'd have to edit each and every Sampler.
The last element is a HTTP Cookie Manager . A Cookie Manager should be added to all web
tests - otherwise JMeter will ignore cookies. By adding it at the Thread Group level, we ensure that
all HTTP requests will share the same cookies.
Logic Controllers can be combined to achieve various results. See the list of built-in Logic
Controllers .
Test Fragments
The Test Fragment element is a special type of controller that exists on the Test Plan tree at the
same level as the Thread Group element. It is distinguished from a Thread Group in that it is not
executed unless it is referenced by either a Module Controlleror an Include_Controller .
This element is purely for code re-use within Test Plans and was introduced in Version 2.5
4.3. Listeners
Listeners provide access to the information JMeter gathers about the test cases while JMeter runs.
The Graph Results listener plots the response times on a graph. The "View Results Tree" Listener
shows details of sampler requests and responses, and can display basic HTML and XML
representations of the response. Other listeners provide summary or aggregation information.
Additionally, listeners can direct the data to a file for later use. Every listener in JMeter provides a
field to indicate the file to store data to. There is also a Configuration button which can be used to
choose which fields to save, and whether to use CSV or XML format. Note that all Listeners save
the same data; the only difference is in the way the data is presented on the screen.
Listeners can be added anywhere in the test, including directly under the test plan. They will
collect data only from elements at or below their level.
There are several listeners that come with JMeter.
4.4. Timers
By default, a JMeter thread sends requests without pausing between each request. We recommend
that you specify a delay by adding one of the available timers to your Thread Group. If you do not
add a delay, JMeter could overwhelm your server by making too many requests in a very short
amount of time.
The timer will cause JMeter to delay a certain amount of time before each sampler which is in its
scope .
If you choose to add more than one timer to a Thread Group, JMeter takes the sum of the timers
and pauses for that amount of time before executing the samplers to which the timers apply.
www.vskills.in
Page 26

Timers can be added as children of samplers or controllers in order to restrict the samplers to
which they are applied.
To provide a pause at a single place in a test plan, one can use the Test ActionSampler.
4.5. Assertions
Assertions allow you to assert facts about responses received from the server being tested. Using an
assertion, you can essentially "test" that your application is returning the results you expect it to.
For instance, you can assert that the response to a query will contain some particular text. The text
you specify can be a Perl-style regular expression, and you can indicate that the response is to
contain the text, or that it should match the whole response.
You can add an assertion to any Sampler. For example, you can add an assertion to a HTTP
Request that checks for the text, "</HTML>". JMeter will then check that the text is present in the
HTTP response. If JMeter cannot find the text, then it will mark this as a failed request.
Note that assertions apply to all samplers which are in its scope . To restrict the assertion to a
single sampler, add the assertion as a child of the sampler.
To view the assertion results, add an Assertion Listener to the Thread Group. Failed Assertions
will also show up in the Tree View and Table Listeners, and will count towards the error %age for
example in the Aggregate and Summary reports.
4.6. Configuration Elements

A configuration element works closely with a Sampler. Although it does not send requests (except
for HTTP(S) Test Script Recorder ), it can add to or modify requests.
A configuration element is accessible from only inside the tree branch where you place the
element. For example, if you place an HTTP Cookie Manager inside a Simple Logic Controller,
the Cookie Manager will only be accessible to HTTP Request Controllers you place inside the
Simple Logic Controller (see figure 1). The Cookie Manager is accessible to the HTTP requests
"Web Page 1" and "Web Page 2", but not "Web Page 3".
Also, a configuration element inside a tree branch has higher precedence than the same element in
a "parent" branch. For example, we defined two HTTP Request Defaults elements, "Web Defaults
1" and "Web Defaults 2". Since we placed "Web Defaults 1" inside a Loop Controller, only "Web
Page 2" can access it. The other HTTP requests will use "Web Defaults 2", since we placed it in the
Thread Group (the "parent" of all other branches).
www.vskills.in
Page 27
Figure 1 - Test Plan Showing Accessability of Configuration Elements
The User Defined VariablesConfiguration element is different. It is processed at the start

of a test, no matter where it is placed. For simplicity, it is suggested that the element is
placed only at the start of a Thread Group.
4.7. PrePre-Processor Elements

A Pre-Processor executes some action prior to a Sampler Request being made. If a Pre-Processor
is attached to a Sampler element, then it will execute just prior to that sampler element running. A
Pre-Processor is most often used to modify the settings of a Sample Request just before it runs, or
to update variables that aren't extracted from response text. See the scoping rules for more details
on when Pre-Processors are executed.
4.8. PostPost-Processor Elements

A Post-Processor executes some action after a Sampler Request has been made. If a PostProcessor is attached to a Sampler element, then it will execute just after that sampler element
runs. A Post-Processor is most often used to process the response data, often to extract values
from it. See the scoping rules for more details on when Post-Processors are executed.
4.9. Execution order

Configuration elements
Pre-Processors
Timers
Sampler
Post-Processors (unless SampleResult is null)
Assertions (unless SampleResult is null)
Listeners (unless SampleResult is null)
Please note that Timers, Assertions, Pre- and Post-Processors are only processed if there is
a sampler to which they apply. Logic Controllers and Samplers are processed in the order
in which they appear in the tree. Other test elements are processed according to the scope
www.vskills.in
Page 28

in which they are found, and the type of test element. [Within a type, elements are
processed in the order in which they appear in the tree].
For example, in the following test plan:
Controller
Post-Processor 1
Sampler 1
Sampler 2
Timer 1
Assertion 1
Pre-Processor 1
Timer 2
Post-Processor 2
The order of execution would be:
Pre-Processor 1
Timer 1
Timer 2
Sampler 1
Post-Processor 1
Post-Processor 2
Assertion 1
Pre-Processor 1
Timer 1
Timer 2
Sampler 2
Post-Processor 1
Post-Processor 2
Assertion 1
4.10. Scoping Rules

The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in
the test trees are strictly hierarchical (Listeners, Config Elements, Post-Procesors, Pre-Processors,
Assertions, Timers), and some are primarily ordered (controllers, samplers). When you create
your test plan, you will create an ordered list of sample request (via Samplers) that represent a set
of steps to be executed. These requests are often organized within controllers that are also
ordered. Given the following test tree:
www.vskills.in
Page 29
Example test tree
The order of requests will be, One, Two, Three, Four.

Some controllers affect the order of their subelements, and you can read about these specific
controllers in the component reference .
Other elements are hierarchical. An Assertion, for instance, is hierarchical in the test tree. If its
parent is a request, then it is applied to that request. If its parent is a Controller, then it affects all
requests that are descendants of that Controller. In the following test tree:
Hierarchy example
Assertion #1 is applied only to Request One, while Assertion #2 is applied to Requests Two and
Three.
Another example, this time using Timers:
complex example
In this example, the requests are named to reflect the order in which they will be executed. Timer
#1 will apply to Requests Two, Three, and Four (notice how order is irrelevant for hierarchical
elements). Assertion #1 will apply only to Request Three. Timer #2 will affect all the requests.
www.vskills.in
Page 30
Hopefully these examples make it clear how configuration (hierarchical) elements are applied. If
you imagine each Request being passed up the tree branches, to its parent, then to its parent's
parent, etc, and each time collecting all the configuration elements of that parent, then you will see
how it works.
The Configuration elements Header Manager, Cookie Manager and Authorization manager are
treated differently from the Configuration Default elements. The settings from the Configuration
Default elements are merged into a set of values that the Sampler
Sampler has access to. However, the
settings from the Managers are not merged. If more than one Manager is in the scope of a
Sampler, only one Manager is used, but there is currently no way to specify which is used.
4.11. Properties and Variables

JMeter properties are defined in jmeter.properties (see Gettting Started - Configuring JMeter for
more details).
Properties are global to jmeter, and are mostly used to define some of the defaults JMeter uses.
For example the property remote_hosts defines the servers that JMeter will try to run remotely.
Properties can be referenced in test plans - seeFunctions - read a property - but cannot be used for
thread-specific values.
JMeter variables are local to each thread. The values may be the same for each thread, or they may
be different.
If a variable is updated by a thread, only the thread copy of the variable is changed. For example
the Regular Expression Extractor Post-Processor will set its variables according to the sample that
its thread has read, and these can be used later by the same thread. For details of how to reference
variables and functions, see Functions and Variables
Note that the values defined by the Test Plan and the User Defined Variablesconfiguration
element are made available to the whole test plan at startup. If the same variable is defined by
multiple UDV elements, then the last one takes effect. Once a thread has started, the initial set of
variables is copied to each thread. Other elements such as the User Parameters Pre-Processor or
Regular Expression Extractor Post-Processor may be used to redefine the same variables (or create
new ones). These redefinitions only apply to the current thread.
The setProperty function can be used to define a JMeter property. These are global to the test
plan, so can be used to pass information between threads - should that be needed.
Both variables and properties are case-sensitive.
4.12. Using Variables to parameterise tests

Variables don't have to vary - they can be defined once, and if left alone, will not change value. So
you can use them as short-hand for expressions that appear frequently in a test plan. Or for items
which are constant during a run, but which may vary between runs. For example, the name of a
host, or the number of threads in a thread group.
www.vskills.in
Page 31

When deciding how to structure a Test Plan, make a note of which items are constant for the run,
but which may change between runs. Decide on some variable names for these - perhaps use a
naming convention such as prefixing them with C_ or K_ or using uppercase only to distinguish
them from variables that need to change during the test. Also consider which items need to be
local to a thread - for example counters or values extracted with the Regular Expression PostProcessor. You may wish to use a different naming convention for these.
For example, you might define the following on the Test Plan:
HOST
THREADS
LOOPS
www.example.com
10
20
You can refer to these in the test plan as ${HOST} ${THREADS} etc. If you later want to change
the host, just change the value of the HOST variable. This works fine for small numbers of tests,
but becomes tedious when testing lots of different combinations. One solution is to use a property
to define the value of the variables, for example:
HOST
THREADS
LOOPS
${__P(host,www.example.com)}
${__P(threads,10)}
${__P(loops,20)}
You can then change some or all of the values on the command-line as follows:
jmeter ... -Jhost=www3.example.org -Jloops=13
www.vskills.in
Page 32
5. BUILDING A WEB TEST PLAN

PLAN
In this section, you will learn how to create a basic Test Plan to test a Web site. You will create five
users that send requests to two pages on the JMeter Web site. Also, you will tell the users to run
their tests twice. So, the total number of requests is (5 users) x (2 requests) x (repeat 2 times) = 20
HTTP requests. To construct the Test Plan, you will use the following elements:Thread Group ,
HTTP Request , HTTP Request Defaults , and Graph Results .
For a more advanced Test Plan, see Building an Advanced Web Test Plan .
5.1. Adding Users

The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and the how many requests they should send.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add --> ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the right
section of the JMeter window (see Figure 5.1 below)
Figure 5.1. Thread Group with Default Values
Start by providing a more descriptive name for our Thread Group. In the name field, enter JMeter
Users.
Next, increase the number of users (called threads) to 5.
In the next field, the Ramp-Up Period, leave the default value of 1 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period
of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have
5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second
www.vskills.in
Page 33

(5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately
start all of your users.
Finally enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. If you enter a loop count value of 1, then JMeter will run your test only once. To
have JMeter repeatedly run your Test Plan, select the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make
them. If you change the name of an element, the tree will be updated with the new text
after you leave the Control Panel (for example, when selecting another tree element).
Figure 5.2. JMeter Users Thread Group
5.2. Adding Default HTTP Request Properties

Properties
Now that we have defined our users, it is time to define the tasks that they will be performing. In
this section, you will specify the default settings for your HTTP requests. And then, in section 5.3,
you will add HTTP Request elements which use some of the default settings you specified here.
Begin by selecting the JMeter Users (Thread Group) element. Click your right mouse button to get
the Add menu, and then select Add --> Config Element --> HTTP Request Defaults. Then, select
this new element to view its Control Panel (see Figure 5.3).
www.vskills.in
Page 34
Figure 5.3. HTTP Request Defaults
Like most JMeter elements, the HTTP Request Defaults Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
Skip to the next field, which is the Web Server's Server Name/IP. For the Test Plan that you are
building, all HTTP requests will be sent to the same Web server, jmeter.apache.org. Enter this
domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The HTTP Request Defaults element does not tell JMeter to send an HTTP request. It
simply defines the default values that the HTTP Request elements use.
See Figure 5.4 for the completed HTTP Request Defaults element
Figure 5.4. HTTP Defaults for our Test Plan
www.vskills.in
Page 35

5.3. Adding Cookie Support
Nearly all web testing should use cookie support, unless your application specifically doesn't use
cookies. To add cookie support, simply add an HTTP Cookie Manager to each Thread Group in
your test plan. This will ensure that each thread gets its own cookies, but shared across all HTTP
Request objects.
To add the HTTP Cookie Manager , simply select the Thread Group , and choose Add -->
Config Element --> HTTP Cookie Manager, either from the Edit Menu, or from the right-click
pop-up menu.
5.4. Adding HTTP Requests

In our Test Plan, we need to make two HTTP requests. The first one is for the JMeter home page
(http://jmeter.apache.org/), and the second one is for the Changes page
(http://jmeter.apache.org/changes.html).
JMeter sends requests in the order that they appear in the tree.
Start by adding the first HTTP Request to the JMeter Users element (Add --> Sampler --> HTTP
Request). Then, select the HTTP Request element in the tree and edit the following properties
(see Figure 5.5):
Change the Name field to "Home Page".
Set the Path field to "/". Remember that you do not have to set the Server Name field because
you already specified this value in the HTTP Request Defaults element.
Figure 5.5. HTTP Request for JMeter Home Page
www.vskills.in
Page 36

Next, add the second HTTP Request and edit the following properties (see Figure 5.6:
Change the Name field to "Changes".
Set the Path field to "/changes.html".
Figure 5.6. HTTP Request for JMeter Changes Page
5.5. Adding a Listener to View Store the Test Results

The final element you need to add to your Test Plan is a Listener . This element is responsible for
storing all of the results of your HTTP requests in a file and presenting a visual model of the data.
Select the JMeter Users element and add a Graph Results listener (Add --> Listener --> Graph
Results). Next, you need to specify a directory and filename of the output file. You can either type
it into the filename field, or select the Browse button and browse to a directory and then enter a
filename.
www.vskills.in
Page 37
Figure 5.7. Graph Results Listener
5.6. Logging in to a webweb-site

It's not the case here, but some web-sites require you to login before permitting you to perform
certain actions. In a web-browser, the login will be shown as a form for the user name and
password, and a button to submit the form. The button generates a POST request, passing the
values of the form items as parameters.
To do this in JMeter, add an HTTP Request, and set the method to POST. You'll need to know
the names of the fields used by the form, and the target page. These can be found out by
inspecting the code of the login page. [If this is difficult to do, you can use the JMeter Proxy
Recorder to record the login sequence.] Set the path to the target of the submit button. Click the
Add button twice and enter the username and password details. Sometimes the login form
contains additional hidden fields. These will need to be added as well.
www.vskills.in
Page 38
Figure 5.8. Sample HTTP login request
www.vskills.in
Page 39
6. BUILDING AN ADVANCED WEB TEST PLAN

In this section, you will learn how to create advanced Test Plans to test a Web site.
For an example of a basic Test Plan, see Building a Web Test Plan .
6.1. Handling User Sessions With URL Rewriting

If your web application uses URL rewriting rather than cookies to save session information, then
you'll need to do a bit of extra work to test your site.
To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the
server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier to
accomplish this. Simply enter the name of your session ID parameter into the modifier, and it will
find it and add it to each request. If the request already has a value, it will be replaced. If "Cache
Session Id?" is checked, then the last found session id will be saved, and will be used if the
previous HTTP sample does not contain a session id.
URL Rewriting Example
Download this example . In Figure 1 is shown a test plan using URL rewriting. Note that the URL
Re-writing modifier is added to the SimpleController, thus assuring that it will only affect requests
under that SimpleController.
Figure 1 - Test Tree
In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to specify
the name of the session ID parameter. There is also a checkbox for indicating that the session ID
should be part of the path (separated by a ";"), rather than a request parameter
Figure 2 - Request parameters
6.2. Using a Header Manager

The HTTP Header Manager lets you customize what information JMeter sends in the HTTP
request header. This header includes properties like "User-Agent", "Pragma", "Referer", etc.
www.vskills.in
Page 40
The HTTP Header Manager , like the HTTP Cookie Manager , should probably be added at the
Thread Group level, unless for some reason you wish to specify different headers for the
differentHTTP Request objects in your test.
www.vskills.in
Page 41
7. BUILDING A DATABASE
DATABASE TEST PLAN
In this section, you will learn how to create a basic Test Plan to test a database server. You will
create fifty users that send 2 SQL requests to the database server. Also, you will tell the users to
run their tests 100 times. So, the total number of requests is (50 users) x (2 requests) x (repeat 100
times) = 10'000 JDBC requests. To construct the Test Plan, you will use the following elements:
Thread Group , JDBC Request , Summary Report .
This example uses the MySQL database driver. To use this driver, its containing .jar file
(ex. mysql-connector-java-X.X.X-bin.jar) must be copied to the JMeter ./lib directory (see
JMeter's Classpath for more details).
7.1. Adding Users

mouse button to get the Add menu, and then select Add --> ThreadGroup .
Start by providing a more descriptive name for our Thread Group. In the name field, enter JDBC
Users.
You will need a valid database, database table, and user-level access to that table. In the
example shown here, the database is 'cloud' and the table name is 'vm_instance'.
www.vskills.in
Page 42

Next, increase the number of users to 50.
In the next field, the Ramp-Up Period, leave the value of 10 seconds. This property tells JMeter
how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 10
seconds, JMeter will finish starting all of your users by the end of the 10 seconds. So, if we have 50
users and a 10 second Ramp-Up Period, then the delay between starting users would be 200
milliseconds (10 seconds / 50 users = 0.2 user per second). If you set the value to 0, then JMeter
will immediately start all of your users.
Finally, enter a value of 100 in the Loop Count field. This property tells JMeter how many times to
repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
See Figure 7.2 for the completed JDBC Users Thread Group.
Figure 7.2. JDBC Users Thread Group
7.2. Adding JDBC Requests

Requests
Now that we have defined our users, it is time to define the tasks that they will be performing. In
this section, you will specify the JDBC requests to perform.
Begin by selecting the JDBC Users element. Click your right mouse button to get the w Add
menu, and then select Add --> Config Element --> JDBC Connection Configuration . Then, select
this new element to view its Control Panel (see Figure 7.3).
Set up the following fields (these assume we will be using a MySQL database called 'cloud'):
Variable name (here: myDatabase) bound to pool. This needs to uniquely identify the
configuration. It is used by the JDBC Sampler to identify the configuration to be used.
Database URL: jdbc:mysql://ipOfTheServer:3306/cloud
JDBC Driver class: com.mysql.jdbc.Driver
Username: the username of database
www.vskills.in
Page 43

Password: password for the username
The other fields on the screen can be left as the defaults.
JMeter creates a database connection pool with the configuration settings as specified in the
Control Panel. The pool is referred to in JDBC Requests in the 'Variable Name' field. Several
different JDBC Configuration elements can be used, but they must have unique names. Every
JDBC Request must refer to a JDBC Configuration pool. More than one JDBC Request can refer
to the same pool.
Figure 7.3. JDBC Configuration
Selecting the JDBC Users element again. Click your right mouse button to get the Add menu, and
then select Add --> Sampler --> JDBC Request . Then, select this new element to view its Control
Panel (see Figure 7.4).
Figure 7.4. JDBC Request
www.vskills.in
Page 44

In our Test Plan, we will make two JDBC requests. The first one is for select all 'Running' VM
instances, and the second is to select 'Expunging' VM instance (obviously you should change these
to examples appropriate for your particular database). These are illustrated below.
JMeter sends requests in the order that you add them to the tree.
Change the Name to 'VM Running'.
Enter the Pool Name: 'myDatabase' (same as in the configuration element)
Enter the SQL Query String field.
Enter the Parameter values field with 'Running' value.
Enter the Parameter types with 'VARCHAR'.
Figure 7.5. JDBC Request for the first SQL request
Next, add the second JDBC Request and edit the following properties (see Figure 7.6):
Change the Name to 'VM Expunging'.
Change the value of Parameter values to 'Expunging'.
www.vskills.in
Page 45
Figure 7.6. JDBC Request for the second request
7.3. Adding a Listener to View/Store the Test Results

storing all of the results of your JDBC requests in a file and presenting the results.
Select the JDBC Users element and add a Summary Report listener ( Add -->
--> Listener -->
-->
Summary Report ).
Save the test plan, and run the test with the menu Run --> Start or Ctrl+R
The listener shows the results.
Figure 7.7. Graph results Listener
www.vskills.in
Page 46
8. BUILDING AN FTP TEST PLAN

In this section, you will learn how to create a basic Test Plan to test an FTP site. You will create
four users that send requests for two files on a FTP site. Also, you will tell the users to run their
tests twice. So, the total number of requests is (4 users) x (2 requests) x (repeat 2 times) = 16 FTP
requests.
To construct the Test Plan, you will use the following elements: Thread Group , FTP Request ,
FTP Request Defaults , and View Results in Table .
8.1. Adding Users

Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add -->
--> ThreadGroup.
ThreadGroup
You should now see the Thread Group element under Test Plan.
Plan If you do not see the element,
Start by providing a more descriptive name for our Thread

Thread Group.
Group In the name field, enter 'FTP
Users'.
Next, increase the number of users to 4.
www.vskills.in
Page 47

JMeter how long to delay between starting each user. For example, if you enter a Ramp-UpPeriod
Finally, enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
See Figure 8.2 for the completed FTP Users Thread Group.
Figure 8.2. FTP Users Thread Group
8.2. Adding Default FTP Request Properties

Now that we have defined our users, it is time define the tasks that they will be performing. In this
section, you will specify the default settings for your FTP requests. And then, in section 8.3, you
will add FTP Request elements which use some of the default settings you specified here.
Begin by selecting the FTP Users element. Click your right mouse button to get the Add menu,
and then select Add --> Config Element --> FTP Request Defaults. Then, select this new element
to view its Control Panel (see Figure 8.3).
www.vskills.in
Page 48
Figure 8.3. FTP Request Defaults
Like most JMeter elements, the FTP Request Defaults Control Panel has a name field that you can
modify. In this example, leave this field with the default value.
Skip to the next field, which is the FTP Server's Server Name/IP. For the Test Plan that you are
building, all FTP requests will be sent to the same FTP server, ftp.domain.com in this case. Enter
this domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The FTP Request Defaults element does not tell JMeter to send an FTP request. It simply defines
the default values that the FTP Request elements use.
Figure 8.4. FTP Defaults for our Test Plan
8.3. Adding FTP Requests

In our Test Plan , we need to make two FTP requests .
Start by adding the first FTP Request to the FTP Users element ( Add --> Sampler
Sample --> FTP
Request ). Then, select the FTP Request element in the tree and edit the following properties (see
Figure 8.5):
Change the Name to "File1".
Change the Remote File field to "/directory/file1.txt".
Change the Username field to "anonymous".
Change the Password field to "anonymous@test.com".
You do not have to set the Server Name field because you already specified this value in the FTP
Request Defaults element.
www.vskills.in
Page 49
Figure 8.5. FTP Request for file1
Next, add the second FTP Request and edit the following properties (see Figure 8.6:
Change the Name to "File2".
Change the Remote File field to "/directory/file2.txt".
Change the Username field to "anonymous".
Change the Password field to "anonymous@test.com".
Figure 8.6. FTP Request for file2

storing all of the results of your FTP requests in a file and presenting a visual model of the data.
Select the FTP Users element and add a View Results in Table listener ( Add --> Listener -->
--> View
Results in Table ).
Run your test and view the results.
www.vskills.in
Page 50
Figure 8.7. View Results in Table Listener
www.vskills.in
Page 51
9. BUILDING AN LDAP TEST

TEST PLAN
In this section, you will learn how to create a basic Test Plan to test an LDAP server. You will
create four users that send requests for four tests on the LDAP server. Also, you will tell the users
to run their tests 4 times. So, the total number of requests is (4 users) x (4 requests) x repeat 4
times) = 40 LDAP requests. To construct the Test Plan, you will use the following elements:
Thread Group , LDAP Request , LDAP Request Defaults , and View Results in Table .
This example assumes that the LDAP Server is available at ldap.test.com.
9.1. Adding Users

mouse button to get the Add menu, and then select Add>
Add ThreadGroup . You should now see the
Thread Group element under Test Plan. If you do not see the element, then "expand" the Test
Plan tree by clicking on the Test Plan element.
Figure 9a.1. Thread Group and final test tree
9.2. Adding Login Config Element

Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu,
and then select Add > Config Element > Login
Login Config Element . Then, select this new element to
view its Control Panel.
Like most JMeter elements, the Login Config Element 's Control Panel has a name field that you
www.vskills.in
Page 52
Figure 9a.2 Login Config Element for our Test Plan
Enter Username field to "your LDAP Username",

The password field to "your LDAP Passowrd"
These values will be used by the LDAP Requests
9.3. Adding LDAP Request Defaults

Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu,
and then select Add > Config Element > LDAP Request Defaults . Then, select this new element
to view its Control Panel.
Like most JMeter elements, the LDAP Request Defaults Control Panel has a name field that you
Figure 9a.3 LDAP Defaults for our Test Plan
Enter DN field to "your LDAP Root Distinguished Name".

Enter LDAP Server's Servername field to "ldap.test.com".
The port to 389.
These values are default for the LDAP Requests.
9.4. Adding LDAP Requests

In our Test Plan, we need to make four LDAP requests.
Inbuilt Add Test
Inbuilt Search Test
Inbuilt Modify Test
Inbuilt Delete Test
www.vskills.in
Page 53

JMeter sends requests in the order that you add them to the tree. Start by adding the first LDAP
Request to the LDAP Users element ( Add > Sampler>
Sampler LDAP Request ). Then, select the LDAP
Request element in the tree and edit the following properties
Rename to "Add" this element
Select the Add Test radio button in Test Configuration group
Figure 9a.4.1 LDAP Request for Inbuilt Add test
You do not have to set the Server Name field, port field, Username, Password and DN because
you already specified this value in the Login Config Element and LDAP Request Defaults.
Defaults
Next, add the second LDAP Request and edit the following properties
Rename to "Search" this element
Select the Search Test radio button in Test Configuration group
Figure 9a.4.2 LDAP Request for Inbuilt Search test
Rename to "Modify" this element

Select the Modify Test radio button in Test Configuration group
www.vskills.in
Page 54
Figure 9a.4.3 LDAP Request for Inbuilt Modify test
Rename to "Delete" this element

Select the Delete Test radio button in Test Configuration group
Figure 9a.4.4 LDAP Request for Inbuilt Delete test

You can add a Response Assertion element. This element will check the received response data by
verifying if the response text is "successful". ( Add >Assertion > Response Assertion ).
Note: A this position in the tree, the Response Assertion will be executed for each LDAP Request.
Select Text Response Radio button in Response Field to Test group
Select Substring Radio button in Pattern Matching Rules group
Click on Add button and add the string "successful" in Pattern to Test field
www.vskills.in
Page 55
Figure 9a.5 LDAP Response Assertion
9a.6 Adding a Listener to View/Store the Test Results

The final element you need to add to your Test Plan is a Listener. This element is responsible for
storing all of the results of your LDAP requests in a file and presenting a visual model of the data.
Select the LDAP Users element and add a View Results in Table ( Add > Listener > View Results
in Table )
Figure 9a.6 View Results in Table Listener
9.6. Building an Extended LDAP Test Plan

Plan
In this section, you will learn how to create a basic Test Plan to test an LDAP server.
As the Extended LDAP Sampler is highly configurable, this also means that it takes some time to
build a correct testplan. You can however tune it exactly up to your needs.
www.vskills.in
Page 56

You will create four users that send requests for four tests on the LDAP server. Also, you will tell
the users to run their tests one time. So, the total number of requests is (1 users) x (9 requests) x
repeat 1 time) = 9 LDAP requests. To construct the Test Plan, you will use the following elements:
Thread Group ,
Adding LDAP Extended Request Defaults ,
Adding LDAP Requests , and
Adding a Listener to View/Store the Test Results
This example assumes that the LDAP Server is available at ldap.test.com.
For the less experienced LDAP users, I build a small LDAP tutorial which shortly explains the
several LDAP operations that can be used in building a complex testplan.
Take care when using LDAP special characters in the distinguished name, in that case (eg, you
want to use a + sign in a distinguished name) you need to escape the character by adding an "\" sign
before that character. extra exception: if you want to add a \ character in a distinguished name (in
an add or rename operation), you need to use 4 backslashes. examples: cn=dolf\+smits to
add/search an entry with the name like cn=dolf+smits cn=dolf \\ smits to search an entry with the
name cn=dolf \ smits cn=c:\\\\log.txt to add an entry with a name like cn=c:\log.txt
9.7. Adding Users

Go ahead and add the Thread Group element by first selecting the Test Plan , clicking your right
mouse button to get the Add menu, and then select Add > Threads (Users
Users)
Users > Thread Group . You
should now see the Thread Group element under Test Plan . If you do not see the element, then
"expand" the Test Plan tree by clicking on the Test Plan element.
Figure 9b.1. Thread Group with Default Values
www.vskills.in
Page 57

9.8. Adding LDAP Extended Request Defaults
Begin by selecting the LDAP Ext Users element. Click your right mouse button to get the Add
menu, and then select Add > Config Element > LDAP Extended Request Defaults . Then, select
this new element to view its Control Panel.
Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name field
that you can modify. In this example, leave this field with the default value.
Figure 9b.2 LDAP Defaults for our Test Plan
For each of the different operations, some default values can be filled in. In All cases, when a
default is filled in, this is used for the LDAP extended requests. For each request, you can override
the defaults by filling in the values in the LDAP extended request sampler. When no value is
entered which is necessary for a test, the test will fail in an unpredictable way!
9.9. Adding LDAP Requests

In our Test Plan, we want to use all 9 LDAP requests.
Thread bind
Search Test
Compare Test
Single bind/unbind Test
Add Test
Modify Test
Rename entry (moddn)
Delete Test
Thread unbind
JMeter sends requests in the order that you add them to the tree.
Adding a requests always start by:
Adding the LDAP Extended Request to the LDAP Ext Users element ( Add > Sampler > LDAP
Ext Request ). Then, select the LDAP Ext Request element in the tree and edit the following
properties.
Adding a Thread bind Request

Rename the element: "1. Thread bind"
Select the "Thread bind" button.
www.vskills.in
Page 58

Enter the hostname value from the LDAP server in the Servername field
Enter the portnumber from the LDAP server (636 : ldap over SSL) in the port field
(Optional) Enter the baseDN in the DN field, this baseDN will be used as thestarting point for
searches, add, deletes etc.
take care that this must be the uppermost shared level for all your request, eg When all
information is stored under ou=Users, dc=test, dc=com, you can use this value in the basedn.
(Optional) Enter the distinguished name from the user you want to use for authentication.
When this field is kept empty, an anonymous bind will be established.
(Optional) Enter the password for the user you want to authenticate with, an empty password
will also lead to an anonymous bind.
(Optional) Enter a value for the connection timeout with LDAP
(Optional) Check the box Use Secure LDAP Protocol if you access with LDAP over SSL
(ldaps)
Figure 9b.3.1. Thread Bind example
Adding a search Request

Rename the element: "2. Search Test"
Select the "Search Test" button.
Optional) enter the searchbase under which you want to perform the search, relative to the
basedn, used in the thread bind request.
When left empty, the basedn is used as a search base, this files is important if you want to use a
"base-entry" or "one-level" search (see below)
Enter the searchfilter, any decent LDAP search filter will do, but for now, use something
simple, like (sn=Doe) or (cn=*)
(Optional) Enter the scope in the scope field, it has three options:
baseobject search
only the given searchbase is used, only for checking attributes or existence.
onelevel search
Only search in one level below given searchbase is used
www.vskills.in
Page 59

subtree search
Searches for object at any point below the given basedn
(Optional) Size limit, specifies the maximum number of returned entries,
(Optional) Time limit, specifies the maximum number of milliseconds, the SERVER can use
for performing the search. it is NOT the maximum time the application will wait.
When a very large returnset is returned, from a very fast server, over a very slow line, you may
have to wait for ages for the completion of the search request, but this parameter will not influence
this.
(Optional) Attributes you want in the search answer. This can be used to limit the size of the
answer, especially when an object has very large attributes (like jpeg Photo). There are three
possibilities:
Leave empty (the default setting must also be empty) This will return all attributes.
Put in one empty value (""), it will request a non-existent attributes, so in reality it returns no
attributes
Put in the attributes, separated by a semi-colon. It will return only the requested attributes
(Optional) Return object. Checked will return all java-object attributes, it will add these to the
requested attributes, as specified above.
Unchecked will mean no java-object attributes will be returned.
(Optional) Dereference aliases. Checked will mean it will follow references, Unchecked says it
will not.
Optional) Parse the search results?. Checked will mean it gets all results in response data,
Unchecked says it will not.
Figure 9b.3.2. search request example
www.vskills.in
Page 60

Adding a Compare Request
Rename the element: "3. Compare Test"
Select the "Compare" button.
enter the entryname form the object on which you want the compare operation to work, relative to
the basedn, eg "cn=jdoe,ou=Users"
Enter the compare filter, this must be in the form "attribute=value", eg "mail=jdoe@test.com"
Figure 9b.3.3. Compare example
Adding a Single bind/unbind

Rename the element: "4. Single bind/unbind Test"
Select the "Single bind/unbind" button.
Enter the FULL distinguished name from the user you want to use for authentication.
eg. cn=jdoe,ou=Users,dc=test,dc=com When this field is kept empty, an anonymous bind
will be established.
4. Enter the password for the user you want to authenticate with, an empty password will also lead
to an anonymous bind.
Take care : This single bind/unbind is in reality two separate operations but cannot easily be split!
Figure 9b.3.4. Single bind/unbind example
www.vskills.in
Page 61

Adding an Add Request
Rename the element: "5. Add Test"
Select the "Add" button.
Enter the distinguished name for the object to add, relative to the basedn.
Add a line in the "add test" table, fill in the attribute and value.
When you need the same attribute more than once, just add a new line, add the attribute again,
and a different value.
All necessary attributes and values must be specified to pass the test, see picture!
(sometimes the server adds the attribute "objectClass=top", this might give a problem.
Figure 9b.3.5. Add request example
Adding a Modify Request

Rename the element: "6. Modify Test"
Select the "Modify test" button.
Enter the distinguished name for the object to modify, relative to the basedn.
Add a line in the "modify test" table, with the "add" button.
You need to enter the attribute you want to modify, (optional) a value, and the opcode. The
meaning of this opcode:
1. add
this will mean that the attribute value (not optional in this case) will be added to the
attribute.
When the attribute is not existing, it will be created and the value added
When it is existing, and defined multi-valued, the new value is added.
www.vskills.in
Page 62

when it is existing, but single valued, it will fail.
2. replace
This will overwrite the attribute with the given new value (not optional here)
When the attribute is not existing, it will be created and the value added
When it is existing, old values are removed, the new value is added.
3. delete
delete
When no value is given, all values will be removed
When a value is given, only that value will be removed
when the given value does not exist, the test will fail
6. (Optional) Add more modifications in the "modify test" table.
All modifications which are specified must succeed, to let the modification test pass. When one
modification fails, NO modifications at all will be made and the entry will remain unchanged.
Figure 9b.3.6. Modify example
Adding a Rename Request (moddn)

Rename the element: "7. Rename entry (moddn)"
Select the "Rename Entry" button.
Enter the name of the entry, relative to the baseDN, in the "old entry name-Field".
that is, if you want to rename "cn=Little John Doe,ou=Users", and you set the baseDN to
"dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users" in the old entry name-field.
Enter the new name of the entry, relative to the baseDN, in the "new distinguished name-Field".
when you only change the RDN, it will simply rename the entry
when you also add a different subtree, eg you change from cn=john doe,ou=Users to cn=john
doe,ou=oldusers, it will move the entry. You can also move a complete subtree (If your LDAP
www.vskills.in
Page 63

server supports this!), eg ou=Users,ou=retired, to ou=oldusers,ou=users, this will move the
complete subtree, plus all retired people in the subtree to the new place in the tree.
Figure 9b.3.8. Rename example
Adding a Delete Request

Rename the element: "8. Delete Test"
Select the "Delete" button.
Enter the name of the entry, relative to the baseDN, in the Delete-Field.
that is, if you want to remove "cn=John Junior Doe,ou=Users,dc=test,dc=com", and you set the
baseDN to "dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users" in the Deletefield.
Figure 9b.3.7. Delete example
Adding an unbind Request

Rename the element: 9. Thread unbind"
Select the "Thread unbind" button. This will be enough as it just closes the current connection.
The information which is needed is already known by the system
www.vskills.in
Page 64
Figure 9b.3.9. Unbind example
9.10. Adding a Listener

Listener to View/Store the Test Results
The final element you need to add to your Test Plan is a Listener. This element is responsible for
storing all of the results of your LDAP requests in a file and presenting a visual model of the
data.Select the Thread group element and add a View Results Tree ( Add > Listener > View
Results Tree )
Figure 9b.4. View Result Tree Listener
In this listener you have three tabs to view, the sampler result, the request and the response data.
The sampler result just contains the response time, the returncode and return message
The request gives a short description of the request that was made, in practice no relevant
information is contained here.
The response data contains the full details of the sent request, as well the full details of the
received answer, this is given in a (self defined) xml-style. The full description can be found
here.
www.vskills.in
Page 65
10. BUILDING A WEBSERVICE

WEBSERVICE TEST PLAN
In this section, you will learn how to create a Test Plan to test a WebService. You will create five
users that send requests to One page. Also, you will tell the users to run their tests twice. So, the
total number of requests is (5 users) x (1 requests) x (repeat 2 times) = 10 HTTP requests. To
construct the Test Plan, you will use the following elements:Thread Group , WebService(SOAP)
Request , and Graph Results .
If the sampler appears to be getting an error from the web service, double check the SOAP
message and make sure the format is correct. In particular, make sure the xmlns attributes are
exactly the same as the WSDL. If the xml namespace is different, the web service will likely return
an error. Xmethods contains a list of public web service for those who want to test their test plan.
10.1. Adding Users

Start by providing a more descriptive name for our Thread Group. In the name field, enter Jakarta
Users.
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period
www.vskills.in
Page 66

Finally, clear the checkbox labeled "Forever", and enter a value of 2 in the Loop Count field. This
property tells JMeter how many times to repeat your test. If you enter a loop count value of 0, then
JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select the
Forever checkbox.
Figure 10.2. Jakarta Users Thread Group
10.2. Adding WebService Requests

In our Test Plan, we will use a .NET web service. Since you're using the web service sampler, we
won't go into the details of writing a web service. If you don't know how to write a web service,
Google for web service and familiarize yourself with writing web services for Java and .NET. It
should be noted there is a significant difference between how .NET and Java implement web
services. The topic is too broad to cover in the user manual. Please refer to other sources to get a
better idea of the differences.
Start by adding the sampler WebService(SOAP) Request to the Jakarta Users element (Add -->
Sampler --> WebService(SOAP) Request). Then, select the web service Request element in the
tree and edit the following properties (see Figure 10.5):
Change the Name field to "WebService(SOAP) Request".
Enter the WSDL URL and click "Load WSDL".
www.vskills.in
Page 67
Figure 10.3. Web service Request
If the WSDL file was loaded correctly, the "Web Methods" drop down should be populated. If the
drop down remains blank, it means there was a problem getting the WSDL. You can test the
WSDL using a browser that reads XML. For example, if you're testing an IIS web service the URL
will look like this: http://localhost/myWebService/Service.asmx?WSDL. At this point,
SOAPAction, URL and SOAP Data should be blank.
Next, select the web method and click "Configure". The sampler should populate the "URL" and
"SOAPAction" text fields. Assuming the WSDL is valid, the correct soap action should be entered.
The last step is to paste the SOAP message in the "SOAP/XML-RPC Data" text area. You can
optionally save the soap message to a file and browse to the location. For convenience, there is a
third option of using a message folder. The sampler will randomly select files from a given folder
and use the text for the soap message.
If you do not want JMeter to read the response from the SOAP Web service, uncheck "Read Soap
Responses." If the test plan is intended to stress test a web service, the box should be unchecked. If
the test plan is a functional test, the box should be checked. When "Read Soap Responses" is
unchecked, no result will be displayed in view result tree or view results in table.
An important note on the sampler. It will automatically use the proxy host and port passed to
JMeter from command line, if those fields in the sampler are left blank. If a sampler has values in
www.vskills.in
Page 68

the proxy host and port text field, it will use the ones provided by the user. If no host or port are
provided and JMeter wasn't started with command line options, the sampler will fail silently. This
behavior may not be what users expect.
Note: If you're using Cassini web server, it does not work correctly and is not a reliable web server.
Cassini is meant to be a simple example and isn't a full blown web server like IIS. Cassini does not
close connections correctly, which causes JMeter to hang or not get the response contents.
Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all other
web services. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and gSoap.
Adding a Listener to View Store the Test Results

Select the Jakarta Users element and add a Graph Results listener (Add --> Listener --> Graph
filename.
www.vskills.in
Page 69
11. BUILDING A JMS POINTPOINT-TOTO-POINT TEST PLAN

In this section, you will learn how to create a Test Plan to test a JMS Point-to-Point messaging
solution. The setup of the test is 1 threadgroup with 5 threads sending 4 messages each through a
request queue. A fixed reply queue will be used for monitoring the reply messages. To construct
the Test Plan, you will use the following elements: Thread Group , JMS Point-to-Point , and
Graph Results .
General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the other
uses queues. Topic messages are commonly known as pub/sub messaging. Topic messaging is
generally used in cases where a message is published by a producer and consumed by multiple
subscribers. A JMS sampler needs the JMS implementation jar files; for example, from Apache
ActiveMQ. See here for the list of jars provided by ActiveMQ 3.0.
11.1. Adding a Thread Group

Start by providing a more descriptive name for our Thread Group. In the name field, enter Pointto-Point.
www.vskills.in
Page 70

In the next field, the Ramp-Up Period, leave set the value to 0 seconds. This property tells JMeter
how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 5
users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5
users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately start
all of your users.
Clear the checkbox labeled "Forever", and enter a value of 4 in the Loop Count field. This
Forever checkbox.
11.2. Adding JMS PointPoint-toto-Point Sampler

Start by adding the sampler JMS Point-to-Point to the Point-to-Point element (Add --> Sampler -->
JMS Point-to-Point). Then, select the JMS Point-to-Point sampler element in the tree. In building
the example a configuration will be provided that works with ActiveMQ 3.0.

storing all of the results of your JMS requests in a file and presenting a visual model of the data.
Select the Thread Group element and add a Graph Results listener (Add --> Listener --> Graph
filename.
www.vskills.in
Page 71
www.vskills.in
Page 72
12. BUILDING A JMS TOPIC TEST PLAN

In this section, you will learn how to create a Test Plan to test JMS Providers. You will create five
subscribers and one publisher. You will create 2 thread groups and set each one to 10 iterations.
The total messages is (6 threads) x (1 message) x (repeat 10 times) = 60 messages. To construct the
Test Plan, you will use the following elements: Thread Group , JMS Publisher , JMS Subscriber ,
and Graph Results .
General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the other
uses queues. Topic messages are commonly known as pub/sub messaging. Topic messaging is
generally used in cases where a message is published by a producer and consumed by multiple
subscribers. Queue messaging is generally used for transactions where the sender expects a
response. Messaging systems are quite different from normal HTTP requests. In HTTP, a single
user sends a request and gets a response. Messaging system can work in synchronous and
asynchronous mode. A JMS sampler needs the JMS implementation jar files; for example, from
Apache ActiveMQ. See here for the list of jars provided by ActiveMQ 3.0.
12.1. Adding Users

The first step is adding a Thread Group element. The Thread Group tells JMeter the number of
users you want to simulate, how often the users should send requests, and how many requests they
should send.
Start by providing a more descriptive name for our Thread Group. In the name field, enter
Subscribers.
www.vskills.in
Page 73

In the next field, the Ramp-Up Period, set the value to 0 seconds. This property tells JMeter how
long to delay between starting each user. For example, if you enter a Ramp-Up Period of 5
users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5
users / 5 seconds = 1 user per second). If you set the value to 0, JMeter will immediately start all
users.
Clear the checkbox labeled "Forever", and enter a value of 10 in the Loop Count field. This
Forever checkbox.
Repeat the process and add another thread group. For the second thread group, enter "Publisher"
in the name field, set the number of threads to 1, and set the iteration to 10.
12.2. Adding JMS Subscriber and Publisher

Make sure the required jar files are in JMeter's lib directory. If they are not, shutdown JMeter,
copy the jar files over and restart JMeter.
Start by adding the sampler JMS Subscriber to the Subscribers element (Add --> Sampler --> JMS
Subscriber). Then, select the JMS Subscriber element in the tree and edit the following properties:
Change the Name field to "Sample Subscriber"
If the JMS provider uses the jndi.properties file, check the box
Enter the name of the InitialContextFactory class. For example, with ActiveMQ 5.4, the value is
"org.apache.activemq.jndi.ActiveMQInitialContextFactory"
Enter the provider URL. This is the URL for the JNDI server, if there is one. For example,
with ActiveMQ 5.4 on local machine with default port, the value is "tcp://localhost:61616"
Enter the name of the connection factory. Please refer to the documentation of the JMS
provider for the information. For ActiveMQ, the default is "ConnectionFactory"
Enter the name of the message topic. For ActiveMQ Dynamic Topics (create topics
dynamically), example value is "dynamicTopics/MyStaticTopic1" Note: Setup at startup mean
that JMeter starting to listen on the Destination at beginning of test without name change
possibility. Setup on Each sample mean that JMeter (re)starting to listen before run each JMS
Subscriber sample, this last option permit to have Destination name with some JMeter variables
If the JMS provider requires authentication, check "required" and enter the username and
password. For example, Orion JMS requires authentication, while ActiveMQ and MQSeries
does not
Enter 10 in "Number of samples to aggregate". For performance reasons, the sampler will
aggregate messages, since small messages will arrive very quickly. If the sampler didn't aggregate
the messages, JMeter wouldn't be able to keep up.
If you want to read the response, check the box
www.vskills.in
Page 74

There are two client implementations for subscribers. If the JMS provider exhibits zombie
threads with one client, try the other.
Figure 12.2. JMS Subscriber
Next add the sampler JMS Publisher to the Publisher element (Add --> Sampler --> JMS
Subscriber). Then, select the JMS Publisher element in the tree and edit the following properties:
Change the Name field to "Sample Publisher".
If the JMS provider uses the jndi.properties file, check the box
Enter the name of the InitialContextFactory class. For example, with ActiveMQ 5.4, the value is
"org.apache.activemq.jndi.ActiveMQInitialContextFactory"
Enter the provider URL. This is the URL for the JNDI server, if there is one. For example,
with ActiveMQ 5.4 on local machine with default port, the value is "tcp://localhost:61616"
Enter the name of the connection factory. Please refer to the documentation of the JMS
provider for the information. For ActiveMQ, the default is "ConnectionFactory"
Enter the name of the message topic. For ActiveMQ Dynamic Topics (create topics
dynamically), example value is "dynamicTopics/MyStaticTopic1". Note: Setup at startup mean
that JMeter starting connection with the Destination at beginning of test without name change
possibility. Setup on Each sample mean that JMeter (re)starting the connection before run each
JMS Publisher sample, this last option permit to have Destination name with some JMeter
variables
If the JMS provider requires authentication, check "required" and enter the username and
password. For example, Orion JMS requires authentication, while ActiveMQ and MQSeries
does not
www.vskills.in
Page 75
Enter 10 in "Number of samples to aggregate". For performance reasons, the sampler will
aggregate messages, since small messages will arrive very quickly. If the sampler didn't aggregate
the messages, JMeter wouldn't be able to keep up.
Select the appropriate configuration for getting the message to publish. If you want the sampler
to randomly select the message, place the messages in a directory and select the directory using
browse.
Select the message type. If the message is in object format or map message, make sure the
message is generated correctly.
Figure 12.3. JMS Publisher

Select the Test Plan element and add a Graph Results listener (Add --> Listener --> Graph
filename.
www.vskills.in
Page 76
www.vskills.in
Page 77
13. BUILDING A MONITOR TEST

TEST PLAN
In this section, you will learn how to create a Test Plan to monitor web servers. Monitors are
useful for a stress testing and system management. Used with stress testing, the monitor provides
additional information about server performance. It also makes it easier to see the relationship
between server performance and response time on the client side. As a system administration tool,
the monitor provides an easy way to monitor multiple servers from one console. The monitor was
designed to work with the status servlet in Tomcat 5. In theory, any servlet container that supports
JMX (Java Management Extension) can port the status servlet to provide the same information.
For those who want to use the monitor with other servlet or EJB containers, Tomcat's status servlet
should work with other containers for the memory statistics without any modifications. To get
thread information, you will need to change the MBeanServer lookup to retrieve the correct
MBeans.
13.1. Adding A Server

The first step is to add a Thread Group element. The Thread Group tells JMeter the number of
threads you want. Always use 1, since we are using JMeter as a monitor. This is very important for
those not familiar with server monitors. As a general rule, using multiple threads for a single server
is bad and can create significant stress.
"expand" the Test Plan tree by clicking on the Test Plan element.
Change the loop count to forever (or some large number) so that enough samples are generated.
13.2. HTTP Auth Manager

Add the HTTP Authorization Manager to the Thread Group element (Add --> Config element -->
HTTP Authorization Manager). Enter the username and password for your web server. Important
www.vskills.in
Page 78

note: the monitor only works with Tomcat5 build 5.0.19 and newer. For instructions on how to
setup Tomcat, please refer to tomcat 5 documentation.
leave the base URL blank
enter the username
enter the password
13.3. Adding HTTP Request

Add the HTTP Request to the Thread Group element (Add --> Sampler --> HTTP Request).
Then, select the HTTP Request element in the tree and edit the following properties):
Change the Name field to "Server Status".
Enter the IP address or Hostname
Enter the port number
Set the Path field to "/manager/status" if you're using Tomcat.
Add a request parameter named "XML" in uppercase. Give it a value of "true" in lowercase.
Check "Use as Monitor" at the bottom of the sampler
13.4. Adding Constant Timer

Add a timer to this thread group (Add --> Timer --> Constant Timer). Enter 5000 milliseconds in
the "Thread Delay" box. In general, using intervals shorter than 5 seconds will add stress to your
server. Find out what is an acceptable interval before you deploy the monitor in your production
environment.
13.5. Adding a Listener to Store the Results

If you want to save the raw results from the server, add a simple data Listener . If you want to save
the calculated statistics, enter a filename in the listener. If you want to save both the raw data and
statistics, make sure you use different filenames.
Select the thread group element and add a Simple Data Writer listener (Add --> Listener -->
Simple Data Writer). Next, you need to specify a directory and filename of the output file. You
can either type it into the filename field, or select the Browse button and browse to a directory and
then enter a filename.
13.6. Adding Monitor Results

Add the Listener by selecting the test plan element (Add --> Listener -- > Monitor Results).
By default, the Listener will select the results from the first connector in the sample response. The
Connector prefix field can be used to select a different connector. If specified, the Listener will
choose the first connector which matches the prefix. If no match is found, then the first connector
is selected.
www.vskills.in
Page 79
There are two tabs in the monitor results listener. The first is the "Health", which displays the status
of the last sample the monitor received. The second tab is "Performance", which shows a historical
view of the server's performance.
A quick note about how health is calculated. Typically, a server will crash if it runs out of memory,
or reached the maximum number of threads. In the case of Tomcat 5, once the threads are maxed
out, requests are placed in a queue until a thread is available. The relative importance of threads
vary between containers, so the current implementation uses 50/50 to be conservative. A container
that is more efficient with thread management might not see any performance degradation, but the
used memory definitely will show an impact.
www.vskills.in
Page 80
The performance graph shows four different lines. The free memory line shows how much free
memory is left in the current allocated block. Tomcat 5 returns the maximum memory, but it is
not graphed. In a well tuned environment, the server should never reach the maximum memory.
Note the graph has captions on both sides of the graph. On the left is percent and the right is
dead/healthy. If the memory line spikes up and down rapidly, it could indicate memory thrashing.
In those situations, it is a good idea to profile the application with Borland OptimizeIt or JProbe.
What you want to see is a regular pattern for load, memory and threads. Any erratic behavior
usually indicates poor performance or a bug of some sort.
www.vskills.in
Page 81
14. INTRODUCTION TO LISTENERS

LISTENERS
A listener is a component that shows the results of the samples. The results can be shown in a tree,
tables, graphs or simply written to a log file. To view the contents of a response from any given
sampler, add either of the Listeners "View Results Tree" or "View Results in table" to a test plan. To
view the response time graphically, add graph results, spline results or distribution graph. The
listeners section of the components page has full descriptions of all the listeners.
The "Configure" button can be used to specify which fields to write to the file, and whether to write
it as CSV or XML. CSV files are much smaller than XML files, so use CSV if you are generating
lots of samples.
The file name can be specified using either a relative or an absolute path name. Relative paths are
resolved relative to the current working directory (which defaults to the bin/ directory). Versions of
JMeter after 2.4 also support paths relative to the directory containing the current test plan (JMX
file). If the path name begins with "~/" (or whatever is in the jmeter.save.saveservice.base_prefix
JMeter property), then the path is assumed to be relative to the JMX file location.
If you only wish to record certain samples, add the Listener as a child of the sampler. Or you can
use a Simple Controller to group a set of samplers, and add the Listener to that. The same
filename can be used by multiple samplers - but make sure they all use the same configuration!
14.1. Default Configuration

The default items to be saved can be defined in the jmeter.properties (or user.properties) file. The
properties are used as the initial settings for the Listener Config pop-up, and are also used for the
log file specified by the -l command-line flag (commonly used for non-GUI test runs).
To change the default format, find the following line in jmeter.properties:
jmeter.save.saveservice.output_format=
The information to be saved is configurable. For maximum information, choose "xml" as the
format and specify "Functional Test Mode" on the Test Plan element. If this box is not checked,
the default saved data includes a time stamp (the number of milliseconds since midnight, January
1, 1970 UTC), the data type, the thread name, the label, the response time, message, and code,
and a success indicator. If checked, all information, including the full response data will be logged.
The following example indicates how to set properties to get a vertical bar ("|") delimited format
that will output results like:.
The corresponding jmeter.properties that need to be set are shown below. One oddity in this
example is that the output_format is set to csv, which typically indicates comma-separated values.
www.vskills.in
Page 82
However, the default_delimiter was set to be a vertical bar instead of a comma, so the csv tag is a
misnomer in this case. (Think of CSV as meaning character separated values)
The full set of properties that affect result file output is shown below.
#--------------------------------------------------------------------------# Results file configuration
#--------------------------------------------------------------------------# This section helps determine how result data will be saved.
# The commented out values are the defaults.
# legitimate values: xml, csv, db. Only xml and csv are currently supported.
#jmeter.save.saveservice.output_format=csv
# true when field should be saved; false otherwise
# assertion_results_failure_message only affects CSV output
#jmeter.save.saveservice.assertion_results_failure_message=false
#
#jmeter.save.saveservice.data_type=true
#jmeter.save.saveservice.label=true
#jmeter.save.saveservice.response_code=true
# response_data is not currently supported for CSV output
#jmeter.save.saveservice.response_data=false
# Save ResponseData for failed samples
#jmeter.save.saveservice.response_data.on_error=false
#jmeter.save.saveservice.response_message=true
#jmeter.save.saveservice.successful=true
#jmeter.save.saveservice.thread_name=true
#jmeter.save.saveservice.time=true
#jmeter.save.saveservice.subresults=true
#jmeter.save.saveservice.assertions=true
#jmeter.save.saveservice.latency=true
#jmeter.save.saveservice.samplerData=false
#jmeter.save.saveservice.responseHeaders=false
#jmeter.save.saveservice.requestHeaders=false
#jmeter.save.saveservice.encoding=false
#jmeter.save.saveservice.bytes=true
#jmeter.save.saveservice.url=false
#jmeter.save.saveservice.filename=false
#jmeter.save.saveservice.hostname=false
#jmeter.save.saveservice.thread_counts=false
www.vskills.in
Page 83

#jmeter.save.saveservice.sample_count=false
#jmeter.save.saveservice.idle_time=false
# Timestamp format
# legitimate values: none, ms, or a format suitable for SimpleDateFormat
#jmeter.save.saveservice.timestamp_format=ms
#jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss.SSS
# Put the start time stamp in logs instead of the end
sampleresult.timestamp.start=true
# Whether to use System.nanoTime() - otherwise only use System.currentTimeMillis()
#sampleresult.useNanoTime=true
# Use a background thread to calculate the nanoTime offset
# Set this to <= 0 to disable the background thread
#sampleresult.nanoThreadSleep=5000
# legitimate values: none, first, all
#jmeter.save.saveservice.assertion_results=none
# For use with Comma-separated value (CSV) files or other formats
# where the fields' values are separated by specified delimiters.
# Default:
#jmeter.save.saveservice.default_delimiter=,
# For TAB, since JMeter 2.3 one can use:
#jmeter.save.saveservice.default_delimiter=\t
#jmeter.save.saveservice.print_field_names=false
# Optional list of JMeter variable names whose values are to be saved in the result data
files.
# Use commas to separate the names. For example:
#sample_variables=SESSION_ID,REFERENCE
# N.B. The current implementation saves the values in XML as attributes,
# so the names must be valid XML names.
# Versions of JMeter after 2.3.2 send the variable to all servers
# to ensure that the correct data is available at the client.
# Optional xml processing instruction for line 2 of the file:
#jmeter.save.saveservice.xml_pi=<?xml-stylesheet type="text/xsl" href="sample.xsl"?>
# Prefix used to identify filenames that are relative to the current base
#jmeter.save.saveservice.base_prefix=~/
www.vskills.in
Page 84

The date format to be used for the timestamp_format is described in SimpleDateFormat . The
timestamp format is used for both writing and reading files. If the format is set to "ms", and the
column does not parse as a long integer, JMeter (2.9+) will try the following formats:
yyyy/MM/dd HH:mm:ss.SSS
yyyy/MM/dd HH:mm:ss
yyyy-MM-dd HH:mm:ss.SSS
yyyy-MM-dd HH:mm:ss
MM/dd/yy HH:mm:ss (this is for compatibility with previous versions; it is not recommended
as a format)
Matching is now also strict (non-lenient). JMeter 2.8 and earlier used lenient mode which could
result in timestamps with incorrect dates (times were usually correct).
Sample Variables
JMeter supports the sample_variables property to define a list of additional JMeter variables which
are to be saved with each sample in the JTL files. The values are written to CSV files as additional
columns, and as additional attributes in XML files. See above for an example.
Sample Result Save Configuration

Listeners can be configured to save different items to the result log files (JTL) by using the Config
popup as shown below. The defaults are defined as described in the Listener Default
Configuration section above. Items with (CSV) after the name only apply to the CSV format; items
with (XML) only apply to XML format. CSV format cannot currently be used to save any items
that include line-breaks.
Configuration dialogue
Note that cookies, method and the query string are saved as part of the "Sampler Data" option.
14.2. nonnon-GUI (batch) test runs

When running in non-GUI mode, the -l flag can be used to create a top-level listener for the test
run. This is in addition to any Listeners defined in the test plan. The configuration of this listener
is controlled by entries in the file jmeter.properties as described in the previous section.
www.vskills.in
Page 85

This feature can be used to specify different data and log files for each test run, for example:
jmeter -n -t testplan.jmx -l testplan_01.jtl -j testplan_01.log
jmeter -n -t testplan.jmx -l testplan_02.jtl -j testplan_02.log
Note that JMeter logging messages are written to the file jmeter.log by default. This file is recreated
each time, so if you want to keep the log files for each run, you will need to rename it using the -j
option as above. The -j option was added in version 2.3.
Versions of JMeter after 2.3.1 support variables in the log file name. If the filename contains
paired single-quotes, then the name is processed as a SimpleDateFormat format applied to the
current date, for example:log_file='jmeter_'yyyyMMddHHmmss'.tmp' . This can be used to
generate a unique name for each test run.
14.3. Resource usage

Listeners can use a lot of memory if there are a lot of samples. Most of the listeners currently keep
a copy of every sample they display, apart from:
Simple Data Writer
BeanShell/BSF Listener
Mailer Visualizer
Monitor Results
Summary Report
The following Listeners no longer need to keep copies of every single sample. Instead, samples
with the same elapsed time are aggregated. Less memory is now needed, especially if most samples
only take a second or two at most.
Aggregate Report
Aggregate Graph
Distribution Graph
To minimize the amount of memory needed, use the Simple Data Writer, and use the CSV
format.
14.4. CSV Log format

The CSV log format depends on which data items are selected in the configuration. Only the
specified data items are recorded in the file. The order of appearance of columns is fixed, and is as
follows:
timeStamp - in milliseconds since 1/1/1970
elapsed - in milliseconds
label - sampler label
responseCode - e.g. 200, 404
responseMessage - e.g. OK
www.vskills.in
Page 86

threadName
dataType - e.g. text
success - true or false
failureMessage - if any
bytes - number of bytes in the sample
grpThreads - number of active threads in this thread group
allThreads - total number of active threads in all groups
URL
Filename - if Save Response to File was used
latency - time to first response
encoding
SampleCount - number of samples (1, unless multiple samples are aggregated)
ErrorCount - number of errors (0 or 1, unless multiple samples are aggregated)
Hostname where the sample was generated
IdleTime - number of milliseconds of 'Idle' time (normally 0)
Variables, if specified
14.5. XML Log format 2.1

The format of the updated XML (2.1) is as follows (line breaks will be different):
<?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">
-- HTTP Sample, with nested samples
<httpSample t="1392" lt="351" ts="1144371014619" s="true"
lb="HTTP Request" rc="200" rm="OK"
tn="Listen 1-1" dt="text" de="iso-8859-1" by="12407">
lb="http://www.apache.org/style/style.css" rc="200" rm="OK"
tn="Listen 1-1" dt="text" de="ISO-8859-1" by="1002">
<responseHeader class="java.lang.String">HTTP/1.1 200 OK
Date: Fri, 07 Apr 2006 00:50:14 GMT
...
Content-Type: text/css
</responseHeader>
<requestHeader class="java.lang.String">MyHeader: MyValue</requestHeader>
<responseData class="java.lang.String">body, td, th {
font-size: 95%;
font-family: Arial, Geneva, Helvetica, sans-serif;
color: black;
background-color: white;
}
...
</responseData>
<cookies class="java.lang.String"></cookies>
www.vskills.in
Page 87

<method class="java.lang.String">GET</method>
<queryString class="java.lang.String"></queryString>
<url>http://www.apache.org/style/style.css</url>
</httpSample>
lb="http://www.apache.org/images/asf_logo_wide.gif"
rc="200" rm="OK" tn="Listen 1-1" dt="bin" de="ISO-8859-1" by="5866">
Date: Fri, 07 Apr 2006 00:50:14 GMT
...
Content-Type: image/gif
</responseHeader>
<responseData class="java.lang.String">http://www.apache.org/asf.gif</responseData>
<responseFile class="java.lang.String">Mixed1.html</responseFile>
<url>http://www.apache.org/asf.gif</url>
</httpSample>
Date: Fri, 07 Apr 2006 00:50:13 GMT
...
Content-Type: text/html; charset=ISO-8859-1
</responseHeader>
<responseData class="java.lang.String">
...
<html>
<head>
...
</head>
<body>
...
</body>
</html>
</responseData>
<url>http://www.apache.org/</url>
</httpSample>
-- nonHTTPP Sample
<sample t="0" lt="0" ts="1144372616082" s="true" lb="Example Sampler"
rc="200" rm="OK" tn="Listen 1-1" dt="text" de="ISO-8859-1" by="10">
www.vskills.in
Page 88

<responseHeader class="java.lang.String"></responseHeader>
<requestHeader class="java.lang.String"></requestHeader>
<responseData class="java.lang.String">Listen 1-1</responseData>
<responseFile class="java.lang.String">Mixed2.unknown</responseFile>
<samplerData class="java.lang.String">ssssss</samplerData>
</sample>
</testResults>
Note that the sample node name may be either "sample" or "httpSample".
14.6. XML Log format 2.2

The format of the JTL files is identical for 2.2 and 2.1. Format 2.2 only affects JMX files.
14.7. Sample Attributes

The sample attributes have the following meaning:
Versions 2.1 and 2.1.1 of JMeter saved the Response Code as "rs", but read it back expecting to
find "rc". This has been corrected so that it is always saved as "rc"; either "rc" or "rs" can be read.
14.8. Saving response data

As shown above, the response data can be saved in the XML log file if required. However, this can
make the file rather large, and the text has to be encoded so that it is still valid XML. Also, images
cannot be included.
Another solution is to use the Post-Processor Save_Responses_to_a_file . This generates a new file
for each sample, and saves the file name with the sample. The file name can then be included in
the sample log output. The data will be retrieved from the file if necessary when the sample log file
is reloaded.
14.9. Loading (reading)

(reading) response data
To view an existing results file, you can use the File "Browse..." button to select a file. If necessary,
just create a dummy testplan with the appropriate Listener in it.
www.vskills.in
Page 89

Results can be read from XML or CSV format files. When reading from CSV results files, the
header (if present) is used to determine which fields were saved. In order to interpret a header-less
CSV file correctly, the appropriate JMeter properties must be set.
14.10. Saving Listener GUI data

JMeter is capable of saving any listener as a PNG file. To do so, select the listener in the left panel.
Click Edit > Save As Image . A file dialog will appear. Enter the desired name and save the
listener.
The Listeners which generate output as tables can also be saved using Copy/Paste. Select the
desired cells in the table, and use the OS Copy short-cut (normally Control+C). The data will be
saved to the clipboard, from where it can be pasted into another application, e.g. a spreadsheet or
text editor.
Figure 1 - Edit > Save As Image
www.vskills.in
Page 90
15. REMOTE TESTING

In the event that your JMeter client machine is unable, performance-wise, to simulate enough users
to stress your server, an option exists to control multiple, remote JMeter engines from a single
JMeter GUI client. By running JMeter remotely, you can replicate a test across many low-end
computers and thus simulate a larger load on the server. One instance of the JMeter GUI client
can control any number of remote JMeter instances, and collect all the data from them. This offers
the following features:
Saving of test samples to the local machine
Management of multiple JMeterEngines from a single machine
No need to copy the test plan to each server - the client sends it to all the servers
However, remote mode does use more resources than running the same number of non-GUI tests
independently. If many server instances are used, the client JMeter can become overloaded, as can
the client network connection.
Note that while you can execute the JMeterEngine on your application server, you need to be
mindful of the fact that this will be adding processing overhead on the application server and thus
your testing results will be somewhat tainted. The recommended approach is to have one or more
machines on the same Ethernet segment as your application server that you configure to run the
JMeter Engine. This will minimize the impact of the network on the test results without impacting
the performance of the application server itself.
Step 0: Configure the nodes
Make sure that all the nodes (client and servers) are running exactly the same version of JMeter. As
far as possible, also use the same version of Java on all systems. Using different versions of Java
may work - but is best avoided.
If the test uses any data files, note that these are not sent across by the client so make sure that
these are available in the appropriate directory on each server. If necessary you can define different
values for properties by editting the user.properties or system.properties files on each server.
These properties will be picked up when the server is started and may be used in the test plan to
affect its behavior (e.g. connecting to a different remote server). Alternatively use different content
in any datafiles used by the test (e.g. if each server must use unique ids, divide these between the
data files)
Step 1: Start the servers
To run JMeter in remote node, start the JMeter server component on all machines you wish to run
on by running the JMETER_HOME/bin/jmeterJMETER_HOME/bin/jmeter-server (unix) or JMETER_HOME/bin/jmeterJMETER_HOME/bin/jmeterserver.bat(windows)
script.
erver.bat
Note that there can only be one JMeter server on each node unless different RMI ports are used.
Since JMeter 2.3.1, the JMeter server application starts the RMI registry itself; there is no need to
start RMI registry separately. To revert to the previous behavior, define the JMeter property
server.rmi.create=false on the server host systems.
www.vskills.in
Page 91

By default, RMI uses a dynamic port for the JMeter server engine. This can cause problems for
firewalls, so versions of JMeter after 2.3.2 will check for the JMeter property server.rmi.localport .
If this is non-zero, it will be used as the local port number for the server engine.
Step 2: Add the server IP to your client's Properties File
Edit the properties file on the controlling JMeter machine . In /bin/jmeter.properties, find the
property named, "remote_hosts", and add the value of your running JMeter server's IP address.
Multiple such servers can be added, comma-delimited.
Note that you can use the -R command line option instead to specify the remote host(s) to use.
This has the same effect as using -r and -Jremote_hosts={serverlist}. E.g. jmeter Rhost1,127.0.0.1,host2
If you define the JMeter property server.exitaftertest=true, then the server will exit after it runs a
single test. See also the -X flag (described below)
Step 3a: Start the JMeter Client from a GUI client
Now you are ready to start the controlling JMeter client. For MS-Windows, start the client with the
script "bin/jmeter.bat". For UNIX, use the script "bin/jmeter". You will notice that the Run menu
contains two new sub-menus: "Remote Start" and "Remote Stop" (see figure 1). These menus
contain the client that you set in the properties file. Use the remote start and stop instead of the
normal JMeter start and stop menu items.
Figure 1 - Run Menu
Step 3b: Start the JMeter from a nonnon-GUI Client

As an alternative, you can start the remote server(s) from a non-GUI (command-line) client. The
command to do this is:
jmeter -n -t script.jmx -r
or
jmeter -n -t script.jmx -R server1,server2...
Other flags that may be useful:
-Gproperty=value - define a property in all the servers (may appear more than once)
-Z - Exit remote servers at the end of the test.
The first example will start whatever servers are defined in the JMeter property remote_hosts; the
second example will define remote_hosts from the list of servers and then run the remote servers.
www.vskills.in
Page 92

The command-line client will exit when all the remote servers have stopped.
15.1. Doing it Manually

In some cases, the jmeter-server script may not work for you (if you are using an OS platform not
anticipated by the JMeter developers). Here is how to start the JMeter servers (step 1 above) with a
more manual process:
Step 1a: Start the RMI Registry
Since JMeter 2.3.1, the RMI registry is started by the JMeter server, so this section does not apply
in the normal case. To revert to the previous behavior, define the JMeter property
server.rmi.create=false on the server host systems and follow the instructions below.
JMeter uses Remote Method Invocation (RMI) as the remote communication mechanism.
Therefore, you need to run the RMI Registry application (which is named, "rmiregistry") that
comes with the JDK and is located in the "bin" directory. Before running rmiregistry, make sure
that the following jars are in your system claspath:
JMETER_HOME/lib/ext/ApacheJMeter_core.jar
JMETER_HOME/lib/jorphan.jar
JMETER_HOME/lib/logkit-1.2.jar
The rmiregistry application needs access to certain JMeter classes. Run rmiregistry with no
parameters. By default the application listens to port 1099.
Step 1b: Start the JMeter Server
Once the RMI Registry application is running, start the JMeter Server. Use the "-s" option with the
jmeter startup script ("jmeter -s").
15.2. Tips
JMeter/RMI requires a connection from the client to the server. This will use the port you chose,
default 1099.
JMeter/RMI also requires a reverse connection in order to return sample results from the server to
the client.
This will use a high-numbered port.
This port can be controlled by jmeter property called client.rmi.localport in jmeter.properties.
If there are any firewalls or other network filters between JMeter client and server, you will need to
make sure that they are set up to allow the connections through. If necessary, use monitoring
software to show what traffic is being generated.
If you're running Suse Linux, these tips may help. The default installation may enable the firewall.
In that case, remote testing will not work properly. The following tips were contributed by Sergey
Ten.
If you see connections refused, turn on debugging by passing the following options.
www.vskills.in
Page 93

Since JMeter 2.3.1, the RMI registry is started by the server; however the options can still be
passed in from the JMeter command line. For example: "jmeter -s Dsun.rmi.loader.logLevel=verbose" (i.e. omit the -J prefixes). Alternatively the properties can be
defined in the system.properties file.
The solution to the problem is to remove the loopbacks 127.0.0.1 and 127.0.0.2 from etc/hosts.
What happens is jmeter-server can't connect to rmiregistry if 127.0.0.2 loopback is not available.
Use the following settings to fix the problem.
Replace
dirname $0`/jmeter -s "$@"
With
HOST="-Djava.rmi.server.hostname=[computer_name][computer_domain]
-Djava.security.policy=`dirname $0`/[policy_file]"
`dirname $0`/jmeter $HOST -s "$@"
Also create a policy file and add [computer_name][computer_domain] line to /etc/hosts.
In order to better support SSH-tunneling of the RMI communication channels used in remote
testing, since JMeter 2.6:
a new property "client.rmi.localport" can be set to control the RMI port used by the
RemoteSampleListenerImpl
To support tunneling RMI traffic over an SSH tunnel as the remote endpoint using a port on
the local machine, loopback interface is now allowed to be used if it has been specified directly
using the Java System Property "java.rmi.server.hostname" parameter.
15.3. Using a different port

By default, JMeter uses the standard RMI port 1099. It is possible to change this. For this to work
successfully, all the following need to agree:
On the server, start rmiregistry using the new port number
On the server, start JMeter with the property server_port defined
On the client, update the remote_hosts property to include the new remote host:port settings
Since Jmeter 2.1.1, the jmeter-server scripts provide support for changing the port. For example,
assume you want to use port 1664 (perhaps 1099 is already used).
On Windows (in a DOS box)
C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER [other options]
On Unix:
$ SERVER_PORT=1664 jmeter-server [other options]
[N.B. use upper case for the environment variable]
www.vskills.in
Page 94

In both cases, the script starts rmiregistry on the specified port, and then starts JMeter in server
mode, having defined the "server_port" property.
The chosen port will be logged in the server jmeter.log file (rmiregistry does not create a log file).
15.4. Using a different sample sender

Listeners in the test plan send their results back to the client JMeter which writes the results to the
specified files By default, samples are sent back synchronously as they are generated. This can
affect the maximum throughput of the server test; the sample result has to be sent back before the
thread can continue. There are some JMeter properties that can be set to alter this behavior.
mode - sample sending mode - default is Standard. This should be set on the client node.
Standard - send samples synchronously as soon as they are generated
Hold - hold samples in an array until the end of a run. This may use a lot of memory on the
server.
DiskStore - store samples in a disk file (under java.io.temp) until the end of a run. The
serialized data file is deleted on JVM exit.
Batch - send saved samples when either the count or time exceeds a threshold, at which point
the samples are sent synchronously. The thresholds can be configured on the server using the
following properties:
num_sample_threshold - number of samples to accumulate, default 100
time_threshold - time threshold, default 60000 ms = 60 seconds
Statistical - send a summary sample when either the count or time exceeds a threshold. The
samples are summarized by thread group name and sample label. The following fields are
accumulated:
elapsed time
latency
bytes
sample count
error count
Other fields that vary between samples are lost.
Stripped - remove responseData from successful samples
StrippedBatch - remove responseData from successful samples, and use Batch sender to send
them.
Asynch - samples are temporarily stored in a local queue. A separate worker thread sends the
samples. This allows the test thread to continue without waiting for the result to be sent back to
the client. However, if samples are being created faster than they can be sent, the queue will
www.vskills.in
Page 95

eventually fill up, and the sampler thread will block until some samples can be drained from the
queue. This mode is useful for smoothing out peaks in sample generation. The queue size can
be adjusted by setting the JMeter property asynch.batch.queue.size (default 100) on the server
node.
Custom implementation : set the mode parameter to your custom sample sender class name.
This must implement the interface SampleSender and have a constructor which takes a single
parameter of type RemoteSampleListener.
The following properties apply to the Batch and Statistical modes:
num_sample_threshold - number of samples in a batch (default 100)
time_threshold - number of milliseconds to wait (default 60 seconds)
www.vskills.in
Page 96
16. BEST PRACTICES

16.1. Always use latest version of JMeter
The performance of JMeter is being constantly improved, so users are highly encouraged to use
the most up to date version
16.2. Limit
Limit the Number of Threads
Your hardware's capabilities will limit the number of threads you can effectively run with JMeter. It
will also depend on how fast your server is (a faster server makes JMeter work harder since it
returns request quicker). The more JMeter works, the less accurate its timing information may
become. The more work JMeter does, the more each thread has to wait to get access to the CPU,
the more inflated the timing information gets. If you need large-scale load testing, consider running
multiple non-GUI JMeter instances on multiple machines. The sample result files can be
combined for subsequent analysis. For testing how JMeter performs on a given platform, the
JavaTest sampler can be used. It does not require any network access so can give some idea as to
the maximum throughput achievable.
JMeter versions since 2.8 have an option to delay thread creation until the thread starts sampling,
i.e. after any thread group delay and the ramp-up time for the thread itself. This allows for a very
large total number of threads, provided that not too many are active concurrently.
16.3. Where to Put the Cookie Manager

16.4. Where to Put the Authorization Manager
Using the HTTP(S) Test Script Recorder
Refer to HTTP(S) Test Script Recorder for details on setting up the recorder. The most important
thing to do is filter out all requests you aren't interested in. For instance, there's no point in
recording image requests (JMeter can be instructed to download all images on a page - see HTTP
Request ). These will just clutter your test plan. Most likely, there is an extension all your files
share, such as .jsp, .asp, .php, .html or the like. These you should "include" by entering ".*\.jsp" as
an "Include Pattern".
Alternatively, you can exclude images by entering ".*\.gif" as an "Exclude Pattern". Depending on
your application, this may or may not be a better way to go. You may also have to exclude
stylesheets, javascript files, and other included files. Test out your settings to verify you are
recording what you want, and then erase and start fresh.
The HTTP(S) Test Script Recorder expects to find a ThreadGroup element with a Recording
Controller under it where it will record HTTP Requests to. This conveniently packages all your
samples under one controller, which can be given a name that describes the test case.
Now, go through the steps of a Test Case. If you have no pre-defined test cases, use JMeter to
record your actions to define your test cases. Once you have finished a definite series of steps, save
the entire test case in an appropriately named file. Then, wipe clean and start a new test case. By
doing this, you can quickly record a large number of test case "rough drafts".
www.vskills.in
Page 97

One of the most useful features of the HTTP(S) Test Script Recorder is that you can abstract out
certain common elements from the recorded samples. By defining some user-defined variables at
the Test Plan level or in User Defined Variableselements, you can have JMeter automatically
replace values in you recorded samples. For instance, if you are testing an app on server
"xxx.example.com", then you can define a variable called "server" with the value of
"xxx.example.com", and anyplace that value is found in your recorded samples will be replaced
with "${server}".
If JMeter does not record any samples, check that the browser really is using the proxy. If the
browser works OK even if JMeter is not running, then the browser cannot be using the proxy.
Some browsers ignore proxy settings for localhost or 127.0.0.1; try using the local hostname or IP
instead.
The error "unknown_ca" probably means that you are trying to record HTTPS, and the browser
has not accepted the JMeter Proxy server certificate.
16.5. User variables

Some test plans need to use different values for different users/threads. For example, you might
want to test a sequence that requires a unique login for each user. This is easy to achieve with the
facilities provided by JMeter.
For example:
Create a text file containing the user names and passwords, separated by commas. Put this in
the same directory as your test plan.
Add a CSV DataSet configuration element to the test plan. Name the variables USER and
PASS.
Replace the login name with ${USER} and the password with ${PASS} on the appropriate
samplers
The CSV Data Set element will read a new line for each thread.
16.6. Reducing resource requirements

Some suggestions on reducing resource usage.
Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl
Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled.
Don't use "View Results Tree" or "View Results in Table" listeners during the load test, use them
only during scripting phase to debug your scripts.
Rather than using lots of similar samplers, use the same sampler in a loop, and use variables
(CSV Data Set) to vary the sample. [The Include Controller does not help here, as it adds all
the test elements in the file to the test plan.]
Don't use functional mode
Use CSV output rather than XML
www.vskills.in
Page 98

Only save the data that you need
Use as few Assertions as possible
Use the most performing scripting language (see JSR223 section)
If your test needs large amounts of data - particularly if it needs to be randomized - create the test
data in a file that can be read with CSV Dataset. This avoids wasting resources at run-time002E
16.7. BeanShell server

The BeanShell interpreter has a very useful feature - it can act as a server, which is accessible by
telnet or http.
If you do wish to use the server, define the following in jmeter.properties:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
In the above example, the server will be started, and will listen on ports 9000 and 9001. Port 9000
will be used for http access. Port 9001 will be used for telnet access. The startup.bsh file will be
processed by the server, and can be used to define various functions and set up variables. The
startup file defines methods for setting and printing JMeter and system properties. This is what you
should see in the JMeter console:
Startup script running
Startup script completed
Httpd started on port: 9000
Sessiond started on port: 9001
As a practical example, assume you have a long-running JMeter test running in non-GUI mode,
and you want to vary the throughput at various times during the test. The test-plan includes a
Constant Throughput Timer which is defined in terms of a property, e.g. ${__P(throughput)}. The
following BeanShell commands could be used to change the test:
printprop("throughput");
curr=Integer.decode(args[0]); // Start value
inc=Integer.decode(args[1]); // Increment
end=Integer.decode(args[2]); // Final value
secs=Integer.decode(args[3]); // Wait between changes
while(curr <= end){
setprop("throughput",curr.toString()); // Needs to be a string here
Thread.sleep(secs*1000);
curr += inc;
}
printprop("throughput");
The script can be stored in a file (throughput.bsh, say), and sent to the server using bshclient.jar.
For example:
www.vskills.in
Page 99
java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
16.8. BeanShell scripting

Overview
Each BeanShell test element has its own copy of the interpreter (for each thread). If the test
element is repeatedly called, e.g. within a loop, then the interpreter is retained between invocations
unless the "Reset bsh.Interpreter before each call" option is selected. For intensive load testing, it is
recommended to use a JSR223 scripting language whose ScriptingEngine implements Compilable,
see JSR223 section below for more details.
Some long-running tests may cause the interpreter to use lots of memory; if this is the case try using
the reset option.
You can test BeanShell scripts outside JMeter by using the command-line interpreter:
$ java -cp bsh-xxx.jar[;other jars as needed] bsh.Interperter file.bsh [parameters]
or
$ java -cp bsh-xxx.jar bsh.Interperter
bsh% source("file.bsh");
bsh% exit(); // or use EOF key (e.g. ^Z or ^D)
Sharing Variables
Variables can be defined in startup (initialization) scripts. These will be retained across invocations
of the test element, unless the reset option is used.\
Scripts can also access JMeter variables using the get() and put() methods of the "vars" variable, for
example:vars.get("HOST"); vars.put("MSG","Successful"); . The get() and put() methods only
support variables with String values, but there are also getObject() and putObject() methods which
can be used for arbitrary objects. JMeter variables are local to a thread, but can be used by all test
elements (not just Beanshell).
If you need to share variables between threads, then JMeter properties can be used:
import org.apache.jmeter.util.JMeterUtils;
String value=JMeterUtils.getPropDefault("name","");
JMeterUtils.setProperty("name", "value");
The sample .bshrc files contain sample definitions of getprop() and setprop() methods.
Another possible method of sharing variables is to use the "bsh.shared" shared namespace. For
example:
if (bsh.shared.myObj == void){
// not yet defined, so create it:
myObj=new AnyObject();
}
www.vskills.in
Page 100

bsh.shared.myObj.process();
Rather than creating the object in the test element, it can be created in the startup file defined by
the JMeter property "beanshell.init.file". This is only processed once.
16.9. Developing script functions in BeanShell, Javascript or Jexl etc.

It's quite hard to write and test scripts as functions. However, JMeter has the JSR223, BSF (and
BeanShell) samplers which can be used instead.
Create a simple Test Plan containing the JSR223 or BSF Sampler and Tree View Listener. Code
the script in the sampler script pane, and test it by running the test. If there are any errors, these
will show up in the Tree View. Also the result of running the script will show up as the response.
Once the script is working properly, it can be stored as a variable on the Test Plan. The script
variable can then be used to create the function call. For example, suppose a BeanShell script is
stored in the variable RANDOM_NAME. The function call can then be coded as
${__BeanShell(${RANDOM_NAME})} . There is no need to escape any commas in the script,
because the function call is parsed before the variable's value is interpolated.
16.10. Parameterising tests

Often it is useful to be able to re-run the same test with different settings. For example, changing
the number of threads or loops, or changing a hostname.
One way to do this is to define a set of variables on the Test Plan, and then use those variables in
the test elements. For example, one could define the variable LOOPS=10, and refer to that in the
Thread Group as ${LOOPS}. To run the test with 20 loops, just change the value of the LOOPS
variable on the Test Plan.
This quickly becomes tedious if you want to run lots of tests in non-GUI mode. One solution to
this is to define the Test Plan variable in terms of a property, for example
LOOPS=${__P(loops,10))} . This uses the value of the property "loops", defaulting to 10 if the
property is not found. The "loops" property can then be defined on the JMeter command-line:
jmeter ... -Jloops=12 ... . If there are a lot of properties that need to be changed together, then one
way to achieve this is to use a set of property files. The appropriate property file can be passed in
to JMeter using the -q command-line option.
JSR223 Elements
For intensive load testing, the recommended scripting language is one whose ScriptingEngine
implements the Compilable interface. Groovy scripting engine implements Compilable. However
neither Beanshell nor Javascript do so as of release date of JMeter 2.10, so it is recommended to
avoid them for intensive load testing. [Note: Beanshell implements the Compilable interface but it
has not been coded - the method just throws an Exception. JMeter has an explicit work-round for
this bug.] When using JSR 223 elements, always set caching key to a unique value to ensure the
script compilation is cached if underlying language supports it. Ensure the script does not use any
variable using ${varName} as caching would take only first value of ${varName}. Instead use :
vars.get("varName")
www.vskills.in
Page 101

Sharing variables between threads and thread groups
Variables are local to a thread; a variable set in one thread cannot be read in another. This is by
design. For variables that can be determined before a test starts, see Parameterising Tests (above).
If the value is not known until the test starts, there are various options:
Store the variable as a property - properties are global to the JMeter instance
Write variables to a file and re-read them.
Use the bsh.shared namespace - see above
Write your own Java classes
www.vskills.in
Page 102
17. HELP! MY BOSS WANTS ME TO LOAD TEST OUR WEB APP!

This is a fairly open-ended proposition. There are a number of questions to be asked first, and
additionally a number of resources that will be needed. You will need some hardware to run the
benchmarks/load-tests from. A number of tools will prove useful. There are a number of products
to consider. And finally, why is Java a good choice to implement a load-testing/Benchmarking
product.
17.1. Questions to ask

What is our anticipated average number of users (normal load) ?
What is our anticipated peak number of users ?
When is a good time to load-test our application (i.e. off-hours or week-ends), bearing in mind that
this may very well crash one or more of our servers ?
Does our application have state ? If so, how does our application manage it (cookies, sessionrewriting, or some other method) ?
What is the testing intended to achieve?
17.2. Resources
The following resources will prove very helpful. Bear in mind that if you cannot locate these
resources, you will become these resources. As you already have your work cut out for you, it is
worth knowing who the following people are, so that you can ask them for help if you need it.
17.3. Network
Who knows our network topology ? If you run into any firewall or proxy issues, this will become
very important. As well, a private testing network (which will therefore have very low network
latency) would be a very nice thing. Knowing who can set one up for you (if you feel that this is
necessary) will be very useful. If the application doesn't scale as expected, who can add additional
hardware ?
17.4. Application
Who knows how our application functions ? The normal sequence is
test (low-volume - can we benchmark our application?)
benchmark (the average number of users)
load-test (the maximum number of users)
test destructively (what is our hard limit?)
The test process may progress from black-box testing to white-box testing (the difference is that the
first requires no knowledge of the application [it is treated as a "black box"] while the second
www.vskills.in
Page 103

requires some knowledge of the application). It is not uncommon to discover problems with the
application during this process, so be prepared to defend your work.
17.5. What platform should I use to run the benchmarks/loadbenchmarks/load-tests ?

This should be a widely-used piece of hardware, with a standard (i.e. vanilla) software installation.
Remember, if you publish your results, the first thing your clients will do is hire a graduate student
to verify them. You might as well make it as easy for this person as you possibly can.
For Windows, Windows XP Professional should be a minimum (the others do not multi-thread
past 50-60 connections, and you probably anticipate more users than that).
Good free platforms include the linuxes, the BSDs, and Solaris Intel. If you have a little more
money, there are commercial linuxes. This may be worth it if you need the support.
For non-Windows platforms, investigate "ulimit -n unlimited" with a view to including it in your
user account startup scripts (.bashrc or .cshrc scripts for the testing account).
As you progress to larger-scale benchmarks/load-tests, this platform will become the limiting factor.
So it's worth using the best hardware and software that you have available. Remember to include
the hardware/software configuration in your published benchmarks.
Don't forget JMeter batch mode. This can be useful if you have a powerful server that supports
Java but perhaps does not have a fast graphics implementation, or where you need to login
remotely. Batch (non-GUI) mode can reduce the network traffic compared with using a remote
display or client-server mode. The batch log file can then be loaded into JMeter on a workstation
for analysis, or you can use CSV output and import the data into a spreadsheet.
17.6. Tools
The following tools will all prove useful. It is definitely worthwhile to become familiar with them.
This should include trying them out, and reading the appropriate documentation (man-pages, infofiles, application --help messages, and any supplied documentation).
ping
This can be used to establish whether or not you can reach your target site. Options can be
specified so that 'ping' provides the same type of route reporting as 'traceroute'.
nslookup/dig
While the user will normally use a human-readable internet address, you may wish to avoid the
overhead of DNS lookups when performing benchmarking/load-testing. These can be used to
determine the unique address (dotted quad) of your target site.
traceroute
If you cannot "ping" your target site, this may be used to determine the problem (possibly a firewall
or a proxy). It can also be used to estimate the overall network latency (running locally should give
the lowest possible network latency - remember that your users will be running over a possibly busy
internet). Generally, the fewer hops the better.
www.vskills.in
Page 104

17.7. What other products are there ?
There are a number of commercial products, which generally have fairly hefty pricetags. If you can
justify it, these are probably the way to go. If, however, these products do not do exactly what you
want, or you are on a limited budget, the following are worth a look. In fact, you should probably
start by trying the Apacheab tool, as it may very well do the job if your requirements are not
particularly complicated.
Apache 'ab' tool

You should definitely start with this one. It handles HTTP 'get' requests very well, and can be
made to handle HTTP 'post' requests with a little effort. Written in 'C', it performs very well, and
offers good (if basic) performance reporting.
HttpUnit
This is worth a look. It is a library (and therefore of more interest to developers) that can be used
to perform HTTP tests/benchmarks. It is intended to be used instead of a web browser (therefore
no GUI) in conjunction with JUnit .
Microsoft WAS
This is definitely worth a look. It has an excellent user interface but it may not do exactly what you
want. If this is the case, be aware that the functionality of this product is not likely to change.
JMeter
If you have non-standard requirements, then this solution offers an open-source community to
provide them (of course, if you are readingthis , you are probably already committed to this one).
This product is free to evolve along with your requirements.
17.8. Why Java ?

Why not Perl or C ?
Well, Perl might be a very good choice except that the Benchmark package seems to give fairly
fuzzy results. Also, simulating multiple users with Perl is a tricky proposition (multiple connections
can be simulated by forking many processes from a shell script, but these will not be threads, they
will be processes). However, the Perl community is very large. If you find that someone has
already written something that seems useful, this could be a very good solution.
C, of course, is a very good choice (check out the Apache ab tool). But be prepared to write all of
the custom networking, threading, and state management code that you will need to benchmark
your application.
Java gives you (for free) the custom networking, threading, and state management code that you
will need to benchmark your application. Java is aware of HTTP, FTP, and HTTPS - as well as
RMI, IIOP, and JDBC (not to mention cookies, URL-encoding, and URL-rewriting). In addition
Java gives you automatic garbage-collection, and byte-code level security.
And once Microsoft moves to a CLR (common language run-time) a Windows Java solution will
not be any slower than any other type of solution on the Windows platform.
www.vskills.in
Page 105
18. FUNCTIONS
JMeter functions are special values that can populate fields of any Sampler or other element in a
test tree. A function call looks like this:
${__functionName(var1,var2,var3)}
Where "__functionName" matches the name of a function.
Parentheses surround the parameters sent to the function, for example ${__time(YMD)} The
actual parameters vary from function to function. Functions that require no parameters can leave
off the parentheses, for example ${__threadNum}.
If a function parameter contains a comma, then be sure to escape this with "\", otherwise JMeter
will treat it as a parameter delimiter. For example:
${__time(EEE\, d MMM yyyy)}
If the comma is not escaped - e.g. ${__javaScript(Math.max(2,5))} - you will get an error such as:
ERROR - jmeter.functions.JavaScript: Error processing Javascript: [Math.max(2]
org.mozilla.javascript.EvaluatorException: missing ) after argument list (#1)
This is because the string "Math.max(2,5)" is treated as being two parameters to the __javascript
function:
Math.max(2 and 5)
Other error messages are possible.
Variables are referenced as follows:
${VARIABLE}
If an undefined function or variable is referenced, JMeter does not report/log an error
error - the
reference is returned unchanged. For example if UNDEF is not defined as a variable, then the
case--sensitive.
value of ${UNDEF} is ${UNDEF}. Variables, functions (and properties) are all case
Versions of JMeter after 2.3.1 trim spaces from variable names
names before use, so for example
${__Random(1,63, LOTTERY )} will use the variable 'LOTTERY' rather than ' LOTTERY '.
List of functions, loosely grouped into types.
www.vskills.in
Page 106
18.1. What can functions do

There are two kinds of functions: user-defined static values (or variables), and built-in functions.
User-defined static values allow the user to define variables to be replaced with their static value
when a test tree is compiled and submitted to be run. This replacement happens once at the
beginning of the test run. This could be used to replace the DOMAIN field of all HTTP requests,
for example - making it a simple matter to change a test to target a different server with the same
test.
Note that variables cannot currently be nested; i.e ${Var${N}} does not work. The __V (variable)
function (versions after 2.2) can be used to do this: ${__V(Var${N})}. In earlier JMeter versions
one can use ${__BeanShell(vars.get("Var${N}")}.
This type of replacement is possible without functions, but was less convenient and less intuitive. It
required users to create default config elements that would fill in blank values of Samplers.
Variables allow one to replace only part of any given value, not just filling in blank values.
www.vskills.in
Page 107

With built-in functions users can compute new values at run-time based on previous response data,
which thread the function is in, the time, and many other sources. These values are generated fresh
for every request throughout the course of the test.
18.2. Where can functions and variables be used?

Functions and variables can be written into any field of any test component (apart from the
TestPlan - see below). Some fields do not allow random strings because they are expecting
numbers, and thus will not accept a function. However, most fields will allow functions.
Functions which are used on the Test Plan have some restrictions. JMeter thread variables will
have not been fully set up when the functions are processed, so variable names passed as
parameters will not be set up, and variable references will not work, so split() and regex() and the
variable evaluation functions won't work. The threadNum() function won't work (and does not
make sense at test plan level). The following functions should work OK on the test plan:
intSum
longSum
machineName
BeanShell
javaScript
jexl
random
time
property functions
log functions
Configuration elements are processed by a separate thread. Therefore functions such as
__threadNum do not work properly in elements such as User Defined Variables. Also note that
variables defined in a UDV element are not available until the element has been processed.
18.3. How to reference variables and functions

Referencing a variable in a test element is done by bracketing the variable name with '${' and '}'.
Functions are referenced in the same manner, but by convention, the names of functions begin
with "__" to avoid conflict with user value names * . Some functions take arguments to configure
them, and these go in parentheses, comma-delimited. If the function takes no arguments, the
parentheses can be omitted.
Argument values that themselves contain commas should be escaped as necessary. If you need to
include a comma in your parameter value, escape it like so: '\,'. This applies for example to the
scripting functions - Javascript, Beanshell, Jexl - where it is necessary to escape any commas that
may be needed in script method calls - e.g.
${__BeanShell(vars.put("name"\,"value"))}
Alternatively, you can define your script as a variable, e.g. on the Test Plan:
www.vskills.in
Page 108

SCRIPT
vars.put("name","value")
The script can then be referenced as follows:

${__BeanShell(${SCRIPT})}
There is no need to escape commas in the SCRIPT variable because the function call is parsed
before the variable is replaced with its value. This works well in conjunction with the BSF or
BeanShell Samplers, as these can be used to test Javascript, Jexl and BeanShell scripts.
Functions
can
reference
variables
and
other
functions,
for
example
${__XPath(${__P(xpath.file),${XPATH})}will use the property "xpath.file" as the file name and the
contents of the variable XPATH as the expression to search for.
JMeter provides a tool to help you construct function calls for various built-in functions, which you
can then copy-paste. It will not automatically escape values for you, since functions can be
parameters to other functions, and you should only escape values you intend as literal.
The value of a variable or function can be reported using the __logn() function. The __logn()
function reference can be used anywhere in the test plan after the variable has been defined.
Alternatively, the Java Request sampler can be used to create a sample containing variable
references; the output will be shown in the appropriate Listener. For versions of JMeter later than
2.3, there is a Debug Sampler that can be used to display the values of variables etc in the Tree
View Listener.
18.4. The Function Helper Dialog

The Function Helper dialog is available from JMeter's Tools menu.
Function Helper Dialog
Using the Function Helper, you can select a function from the pull down, and assign values for its
arguments. The left column in the table provides a brief description of the argument, and the right
column is where you write in the value for that argument. Different functions take different
arguments.
www.vskills.in
Page 109

Once you have done this, click the "generate" button, and the appropriate string is generated for
you to copy-paste into your test plan wherever you like.
18.5. Functions
regexFunction
The Regex Function is used to parse the previous response (or the value of a variable) using any
regular expression (provided by user). The function returns the template string with variable values
filled in.
The __regexFunction can also store values for future use. In the sixth parameter, you can specify a
reference name. After this function executes, the same values can be retrieved at later times using
the syntax for user-defined values. For instance, if you enter "refName" as the sixth parameter you
will be able to use:
${refName} to refer to the computed result of the second parameter ("Template for the
replacement string") parsed by this function
${refName_g0} to refer to the entire match parsed by this function.
${refName_g1} to refer to the first group parsed by this function.
${refName_g#} to refer to the n th group parsed by this function.
${refName_matchNr} to refer to the number of groups found by this function.
Parameters
Attribute
Description
Required
The first argument is the regular expression to be applied to the response
data. It will grab all matches. Any parts of this expression that you wish to
use in your template string, be sure to surround in parentheses. Example: <a
First
href="(.*)">. This will grab the value of the link and store it as the first group Yes
argument
(there is only 1 group). Another example: <input type="hidden" name="(.*)"
value="(.*)">. This will grab the name as the first group, and the value as the
second group. These values can be used in your template string
This is the template string that will replace the function at run-time. To refer
Second
to a group captured in the regular expression, use the syntax: Yes
argument
$[group_number]$. Ie: $1$, or $2$. Your template can be any string.
The third argument tells JMeter which match to use. Your regular
expression might find numerous matches. You have four choices:
An integer - Tells JMeter to use that match. '1' for the first found match, '2'
for the second, and so on
Third
RAND - Tells JMeter to choose a match at random.
No,
argument ALL - Tells JMeter to use all matches, and create a template string for each default=1
one and then append them all together. This option is little used.
A float number between 0 and 1 - tells JMeter to find the Xth match using
the formula: (number_of_matches_found * float_number) rounded to
nearest integer.
Fourth
If 'ALL' was selected for the above argument value, then this argument will No
www.vskills.in
Page 110

Attribute
Description
Required
argument be inserted between each appended copy of the template value.
Fifth
Default value returned if no match is found
No
argument
A reference name for reusing the values parsed by this function.
Sixth
Stored values are ${refName} (the replacement template string) and
No
argument ${refName_g#} where "#" is the group number from the regular expression
("0" can be used to refer to the entire match).
Seventh Input variable name. If specified, then the value of the variable is used as the
No
argument input instead of using the previous sample result.
counter
The counter generates a new number each time it is called, starting with 1 and incrementing by +1
each time. The counter can be configured to keep each simulated user's values separate, or to use
the same counter for all users. If each user's values is incremented separately, that is like counting
the number of iterations through the test plan. A global counter is like counting how many times
that request was run.
The counter uses an integer variable to hold the count, which therefore has a maximum of
2,147,483,647.
The counter function instances are now completely independent. [JMeter 2.1.1 and earlier used a
fixed thread variable to keep track of the per-user count, so multiple counter functions operated on
the same value.] The global counter - "FALSE" - is separately maintained by each counter instance.
Multiple __counter function calls in the same iteration won't increment the value further.
If you want to have a count that increments for each sample, use the function in a Pre-Processor
such as User Parameters .
Parameters
Attribute
First
argument
Second
argument
Description
Required
TRUE if you wish each simulated user's counter to be kept
independent and separate from the other users. FALSE for a global Yes
counter.
A reference name for reusing the value created by this function.
Stored values are of the form ${refName}. This allows you to keep one
No
counter and refer to its value in multiple places. [For JMeter 2.1.1 and
earlier this parameter was required.]
threadNum
The thread number function simply returns the number of the thread currently being executed.
These numbers are independent of ThreadGroup, meaning thread #1 in one threadgroup is
indistinguishable from thread #1 in another threadgroup, from the point of view of this function.
www.vskills.in
Page 111

There are no arguments for this function.
intSum
The intSum function can be used to compute the sum of two or more integer values.
Attribute
Description
Required
First
The first int value.
Yes
argument
Second
The second int value.
Yes
argument
nth
The nth int value.
No
argument
A reference name for reusing the value computed by this function. If
last
specified, the reference name must contain at least one non-numeric No
argument
character otherwise it will be treated as another int value to be added.
longSum
The longSum function can be used to compute the sum of two or more long values.
Parameters
Attribute
First
argument
Second
argument
nth
argument
last
argument
Description
Required
The first long value.
Yes
The second long value.
Yes
The nth long value.
No
A reference name for reusing the value computed by this function. If

specified, the reference name must contain at least one non-numeric No
character otherwise it will be treated as another long value to be added.
StringFromFile
The StringFromFile function can be used to read strings from a text file. This is useful for running
tests that require lots of variable data. For example when testing a banking application, 100s or
1000s of different account numbers might be required.
Each time it is called it reads the next line from the file. All threads share the same instance, so
different threads will get different lines. When the end of the file is reached, it will start reading
again from the beginning, unless the maximum loop count has been reached. If there are multiple
references to the function in a test script, each will open the file independently, even if the file
names are the same. [If the value is to be used again elsewhere, use different variable names for
each function call.]
www.vskills.in
Page 112

If an error occurs opening or reading the file, then the function returns the string "**ERR**"
Parameters
Attribute
File Name
Variable
Name
Start
sequence
number
End
sequence
number
Description
Required
Path to the file name. (The path can be relative to the JMeter launch
directory) If using optional sequence numbers, the path name should be Yes
suitable for passing to DecimalFormat. See below for examples.
A reference name - refName - for reusing the value created by this
function. Stored values are of the form ${refName}. Defaults to No
"StringFromFile_".
Initial Sequence number (if omitted, the End sequence number is treated
No
as a loop count)
Final sequence number (if omitted, sequence numbers can increase
No
without limit)
The file name parameter is resolved when the file is opened or re-opened.
The reference name parameter (if supplied) is resolved every time the function is executed.
Using sequence numbers:

When using the optional sequence numbers, the path name is used as the format string for
java.text.DecimalFormat. The current sequence number is passed in as the only parameter. If the
optional start number is not specified, the path name is used as is. Useful formatting sequences
are:
# - insert the number, with no leading zeros or spaces
000 - insert the number packed out to 3 digits with leading zeros if necessary
Examples:
pin#'.'dat -> pin1.dat, ... pin9.dat, pin10.dat, ... pin9999.dat
pin000'.'dat -> pin001.dat ... pin099.dat ... pin999.dat ... pin9999.dat
pin'.'dat# -> pin.dat1, ... pin.dat9 ... pin.dat999
If more digits are required than there are formatting characters, the number will be
expanded as necessary.
To prevent a formatting character from being interpreted, enclose it in single quotes. Note that "."
is a formatting character, and must be enclosed in single quotes (though #. and 000. work as
expected in locales where the decimal point is also ".")
In other locales (e.g. fr), the decimal point is "," - which means that "#." becomes "nnn,".
See the documentation for DecimalFormat for full details.
www.vskills.in
Page 113

If the path name does not contain any special formatting characters, the current sequence number
will be appended to the name, otherwise the number will be inserted according to the formatting
instructions.
If the start sequence number is omitted, and the end sequence number is specified, the sequence
number is interpreted as a loop count, and the file will be used at most "end" times. In this case the
filename is not formatted.
${_StringFromFile(PIN#'.'DAT,,1,2)} - reads PIN1.DAT, PIN2.DAT
${_StringFromFile(PIN.DAT,,,2)} - reads PIN.DAT twice
Note that the "." in PIN.DAT above should not be quoted. In this case the start number is omitted,
so the file name is used exactly as is.
machineName
The machineName function returns the local host name
Parameters
Attribute
Description
Required
Variable Name A reference name for reusing the value computed by this function. No
machineIP
The machineIP function returns the local IP address
Parameters
Attribute
Description
Required
__javaScript
The javaScript function executes a piece of JavaScript (not Java!) code and returns its value
The JMeter Javascript function calls a standalone JavaScript interpreter. Javascript is used as a
scripting language, so you can do calculations etc.
For details of the language, please see Mozilla Rhino Overview
The following variables are made available to the script:
log - the logger for the function
ctx - JMeterContext object
vars - JMeterVariables object
threadName - String containing the current thread name (in 2.3.2 it was misspelt as
"theadName")
sampler - current Sampler object (if any)
sampleResult - previous SampleResult object (if any)
www.vskills.in
Page 114

props - JMeter Properties object
Rhinoscript allows access to static methods via its Packages object. See the Scripting Java
documentation. For example one can access the JMeterContextService static methods
thus:Packages.org.apache.jmeter.threads.JMeterContextService.getTotalThreads()
Parameters
Attribute
Description
Required
The JavaScript expression to be executed. For example:
new Date() - return the current date and time
Math.floor(Math.random()*(${maxRandom}+1)) - a random number
between 0 and the variable maxRandom
Yes
Expression
${minRandom}+Math.floor(Math.random()*(${maxRandom}${minRandom}+1)) - a random number between the variables minRandom
and maxRandom
"${VAR}"=="abcd"
Variable
A reference name for reusing the value computed by this function.
No
Name
Random
The random function returns a random number that lies between the given min and max values.
Parameters
Attribute
Description
Required
Minimum value A number
Yes
Maximum value A bigger number
Yes
RandomString
The RandomString function returns a random String of length using characters in chars to use.
Parameters
Attribute
Description
Required
Length
A number length of generated String
Yes
Characters to use Chars used to generate String
No
UUID
The UUID function returns a pseudo random type 4 Universally Unique IDentifier (UUID).
CSVRead
The CSVRead function returns a string from a CSV file (c.f. StringFromFile )
www.vskills.in
Page 115

NOTE: versions up to 1.9.1 only supported a single file. JMeter versions since 1.9.1 support
multiple file names.
In most cases, the newer CSV Data Set Config element is easier to use.
When a filename is first encountered, the file is opened and read into an internal array. If a blank
line is detected, this is treated as end of file - this allows trailing comments to be used (N.B. this
feature was introduced in versions after 1.9.1)
All subsequent references to the same file name use the same internal array. N.B. the filename
case is significant to the function, even if the OS doesn't care, so CSVRead(abc.txt,0) and
CSVRead(aBc.txt,0) would refer to different internal arrays.
The *ALIAS feature allows the same file to be opened more than once, and also allows for shorter
file names.
Each thread has its own internal pointer to its current row in the file array. When a thread first
refers to the file it will be allocated the next free row in the array, so each thread will access a
different row from all other threads. [Unless there are more threads than there are rows in the
array.]
Note: the function splits the line at every comma by default. If you want to enter columns
containing commas, then you will need to change the delimiter to a character that does not appear
in any column data, by setting the property: csvread.delimiter
Parameters
Attribute
Description
Required
Required
File Name The file (or *ALIAS) to read from
Yes
Column
The column number in the file. 0 = first column, 1 = second etc. "next" - go
Yes
number
to next line of file. *ALIAS - open a file and assign it to the alias
For example, you could set up some variables as follows:
COL1a ${__CSVRead(random.txt,0)}
COL2a ${__CSVRead(random.txt,1)}${__CSVRead(random.txt,next)}
COL1b ${__CSVRead(random.txt,0)}
COL2b ${__CSVRead(random.txt,1)}${__CSVRead(random.txt,next)}
This would read two columns from one line, and two columns from the next available line. If all
the variables are defined on the same User Parameters Pre-Processor, then the lines will be
consecutive. Otherwise, a different thread may grab the next line.
property
The property function returns the value of a JMeter property. If the property value cannot be
found, and no default has been supplied, it returns the property name. When supplying a default
value, there is no need to provide a function name - the parameter can be set to null, and it will be
ignored.
For example:
${__property(user.dir)} - return value of user.dir
www.vskills.in
Page 116

${__property(user.dir,UDIR)} - return value of user.dir and save in UDIR
${__property(abcd,ABCD,atod)} - return value of property abcd (or "atod" if not defined) and
save in ABCD
${__property(abcd,,atod)} - return value of property abcd (or "atod" if not defined) but don't
save it
Parameters
Attribute
Description
Required
Property Name
The property name to be retrieved.
Yes
Variable Name A reference name for reusing the value computed by this function.
No
Default Value
The default value for the property.
No
P
This is a simplified property function which is intended for use with properties defined on the
command line. Unlike the __property function, there is no option to save the value in a variable,
and if no default value is supplied, it is assumed to be 1. The value of 1 was chosen because it is
valid for common test variables such as loops, thread count, ramp up etc.
For example:
Define the property value:
jmeter -Jgroup1.threads=7 -Jhostname1=www.realhost.edu
Fetch the values:
${__P(group1.threads)} - return the value of group1.threads
${__P(group1.loops)} - return the value of group1.loops
${__P(hostname,www.dummy.org)} - return value of
www.dummy.org if not defined
property
hostname
or
In the examples above, the first function call would return 7, the second would return 1 and the
last would return www.dummy.org (unless those properties were defined elsewhere!)
Parameters
Attribute
Description
Required
Property Name
The property name to be retrieved.
Yes
Default Value The default value for the property. If omitted, the default is set to "1".
No
log
The log function logs a message, and returns its input string
Parameters
www.vskills.in
Page 117

Attribute
Description
Required
String to be
A string
Yes
logged
Log Level
OUT, ERR, DEBUG, INFO (default), WARN or ERROR
No
Throwable text If non-empty, creates a Throwable to pass to the logger
No
If present, it is displayed in the string. Useful for identifying what is
Comment
No
being logged.
The OUT and ERR log level names are used to direct the output to System.out and System.err
respectively. In this case, the output is always printed - it does not depend on the current log
setting.
For example:
${__log(Message)} - written to the log file as "...thread Name : Message"
${__log(Message,OUT)} - written to console window
${__log(${VAR},,,VAR=)} - written to log file as "...thread Name VAR=value"
logn
The logn function logs a message, and returns the empty string
Parameters
Attribute
Description
String to be
A string
logged
Log Level
OUT, ERR, DEBUG, INFO (default), WARN or ERROR
Throwable text If non-empty, creates a Throwable to pass to the logger
If present, it is displayed in the string. Useful for identifying what is
Comment
being logged.
Required
Yes
No
No
No
The OUT and ERR log level names are used to direct the output to System.out and System.err
respectively. In this case, the output is always printed - it does not depend on the current log
setting.
For example:
example:
${__logn(VAR1=${VAR1},OUT)} - write the value of the variable to the console window
BeanShell
The BeanShell function evaluates the script passed to it, and returns the result.
For full details on using BeanShell, please see the BeanShell web-site at http://www.beanshell.org/
Note that a different Interpreter is used for each independent occurrence of the function in a test
script, but the same Interpreter is used for subsequent invocations. This means that variables
persist across calls to the function.
www.vskills.in
Page 118

A single instance of a function may be called from multiple threads. However the function
execute() method is synchronized.
If the property "beanshell.function.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: BeanShellFunction.bshrc.
The following variables are set before the script is executed:
log - the logger for the BeanShell function (*)
ctx - the current JMeter context variable
vars - the current JMeter variables
threadName - the threadName (String)
Sampler the current Sampler, if any
SampleResult - the current SampleResult, if any
(*) means that this is set before the init file, if any, is processed. Other variables vary from
invocation to invocation.
Parameters
Attribute
Description
Required
BeanShell script A beanshell script (not a file name)
Yes
Name of variable A reference name for reusing the value computed by this function. No
Example:
${__BeanShell(123*456)} - returns 56088
${__BeanShell(source("function.bsh"))} - processes the script in function.bsh
split
The split function splits the string passed to it according to the delimiter, and returns the original
string. If any delimiters are adjacent, "?" is returned as the value. The split strings are returned in
the variables ${VAR_1}, ${VAR_2} etc. The count of variables is returned in ${VAR_n}. From
JMeter 2.1.2 onwards, a trailing delimiter is treated as a missing variable, and "?" is returned. Also,
to allow it to work better with the ForEach controller, __split now deletes the first unused variable
in case it was set by a previous split.
Example:
Define VAR="a||c|" in the test plan.
${__split(${VAR},VAR,|)}
This will return the contents of VAR, i.e. "a||c|" and set the following variables:
VAR_n=4 (3 in JMeter 2.1.1 and earlier)
VAR_1=a
VAR_2=?
VAR_3=c
VAR_4=? (null in JMeter 2.1.1 and earlier)
www.vskills.in
Page 119

VAR_5=null (in JMeter 2.1.2 and later)
Parameters
Attribute
Description
Required
String to split A delimited string, e.g. "a|b|c"
Yes
Name
of
A reference name for reusing the value computed by this function.
Yes
variable
The delimiter character, e.g. | . If omitted, , is used. Note that , would
No
Delimiter
need to be specified as \, .
XPath
The XPath function reads an XML file and matches the XPath. Each time the function is called,
the next match will be returned. At end of file, it will wrap around to the start. If no nodes
matched, then the function will return the empty string, and a warning message will be written to
the JMeter log file.
Example:
${__XPath(/path/to/build.xml, //target/@name)}
This will match all targets in build.xml and return the contents of the next name attribute
Parameters
Attribute
Description
Required
Attribute
XML file to parse a XML file to parse
Yes
XPath
a XPath expression to match nodes in the XML file Yes
setProperty
The setProperty function sets the value of a JMeter property. The default return value from the
function is the empty string, so the function call can be used anywhere functions are valid.
The original value can be returned by setting the optional 3rd parameter to "true".
Properties are global to JMeter, so can be used to communicate between threads and thread
groups
Parameters
Attribute
Description
Required
Property Name
The property name to be set.
Yes
Property Value
The value for the property.
Yes
True/False Should the original value be returned?
No
www.vskills.in
Page 120

time
The time function returns the current time in various formats.
Parameters
Attribute
Description
Required
The format to be passed to SimpleDateFormat. The function supports
Format
various shorthand aliases, see below. If ommitted, the function returns the No
current time in milliseconds since the epoch.
Name of
The name of the variable to set.
No
variable
If the format string is omitted, then the function returns the current time in milliseconds since the
epoch. In versions of JMeter after 2.7, if the format matches "/ddd" (where ddd are decimal digits),
then the function returns the current time in milliseconds divided by the value of ddd. For
example, "/1000" returns the current time in seconds since the epoch. Otherwise, the current time
is passed to SimpleDateFormat. The following shorthand aliases are provided:
YMD = yyyyMMdd
HMS = HHmmss
YMDHMS = yyyyMMdd-HHmmss
USER1 = whatever is in the Jmeter property time.USER1
USER2 = whatever is in the Jmeter property time.USER2
The defaults can be changed by setting the appropriate JMeter property, e.g. time.YMD=yyMMdd
________________________________________
jexl
The jexl function returns the result of evaluating a Commons JEXL expression . See links below
for more information on JEXL expressions.
The __jexl function uses Commons JEXL 1, and the __jexl2 function uses Commons JEXL 2
JEXL syntax description
JEXL examples
Parameters
Attribute
Description
Required
Expression The expression to be evaluated. For example, 6*(5+2) Yes
Name of variable The name of the variable to set.
No
The following variables are made available to the script:
log - the logger for the function
ctx - JMeterContext object
www.vskills.in
Page 121

vars - JMeterVariables object
threadName - String containing the current thread name (in 2.3.2 it was misspelt as
"theadName")
sampler - current Sampler object (if any)
sampleResult - previous SampleResult object (if any)
OUT - System.out - e.g. OUT.println("message")
Jexl can also create classes and call methods on them, for example:
Systemclass=log.class.forName("java.lang.System");
now=Systemclass.currentTimeMillis(); Note that the Jexl documentation on the web-site
wrongly suggests that "div" does integer division. In fact "div" and "/" both perform normal
division. One can get the same effect as follows: i= 5 / 2; i.intValue(); // or use i.longValue()
V
The V (variable) function returns the result of evaluating a variable name expression. This can be
used to evaluate nested variable references (which are not currently supported).
For example, if one has variables A1,A2 and N=1:
${A1} - works OK
${A${N}} - does not work (nested variable reference)
${__V(A${N})} - works OK. A${N} becomes A1, and the __V function returns the value of A1
Parameters
Attribute
Description
Required
Variable name The variable to be evaluated. Yes
evalVar
evalVar
The eval function returns the result of evaluating an expression stored in a variable.
This allows one to read a string from a file, and process any variable references in it. For example,
if the variable "query" contains "select ${column} from ${table}" and "column" and "table" contain
"name" and "customers", then ${__evalVar(query)} will evaluate as "select name from customers".
Parameters
Attribute
Description
Required
eval
The eval function returns the result of evaluating a string expression.
www.vskills.in
Page 122

This allows one to interpolate variable and function references in a string which is stored in a
variable. For example, given the following variables:
name=Smith
column=age
table=birthdays
SQL=select ${column} from ${table} where name='${name}'
then ${__eval(${SQL})} will evaluate as "select age from birthdays where name='Smith'".
This can be used in conjunction with CSV Dataset, for example where the both SQL statements
and the values are defined in the data file.
Parameters
Attribute
Description
Required
char
The char function returns the result of evaluating a list of numbers as Unicode characters. See also
__unescape(), below.
This allows one to add arbitrary character values into fields.
Parameters
Attribute
Description
Required
Unicode
character The decimal number (or hex number, if prefixed by 0x, or
number (decimal or octal, if prefixed by 0) to be converted to a Unicode Yes
0xhex)
character.
Examples:
Examples:
${__char(13,10)} = ${__char(0xD,0xA)} = ${__char(015,012)} = CRLF
${__char(165)} = (yen)
unescape
The unescape function returns the result of evaluating a Java-escaped string. See also __char()
above.
This allows one to add characters to fields which are otherwise tricky (or impossible) to define via
the GUI.
Parameters
www.vskills.in
Page 123

Attribute
Description
Required
String to unescape The string to be unescaped. Yes
Examples:
${__unescape(\r\n)} = CRLF
${__unescape(1\t2)} = 1[tab]2
unescapeHtml
Function to unescape a string containing HTML entity escapes to a string containing the actual
Unicode characters corresponding to the escapes. Supports HTML 4.0 entities.
For example, the string "<Français>" will become "<Franais>" .
If an entity is unrecognized, it is left alone, and inserted verbatim into the result string. e.g.
">&zzzz;x" will become">&zzzz;x" .
Uses StringEscapeUtils#unescapeHtml(String) from Commons Lang.
Parameters
Attribute
Description
Required
String to escape The string to be escaped. Yes
escapeHtml
Function which escapes the characters in a String using HTML entities. Supports HTML 4.0
entities.
For example, "bread" & "butter" becomes: "bread" & "butter" .
Uses StringEscapeUtils#escapeHtml(String) from Commons Lang.
Parameters
Attribute
Description
Required
String to decode The string with URL encoded chars to decode. Yes
urldecode
Function to decode a application/x-www-form-urlencoded string. Note: use UTF-8 as the encoding
scheme.
For example, the string Word+%22school%22+is+%22%C3%A9cole%22+in+french would get
converted to Word "school" is "cole" in french .
www.vskills.in
Page 124

Uses Java class URLDecoder .
Parameters
Attribute
Description
Required
String to encode String to encode in URL encoded chars. Yes
urlencode
Function to encode a string to a application/x-www-form-urlencoded string.
For example, the string Word "school" is "cole" in french would get converted
toWord+%22school%22+is+%22%C3%A9cole%22+in+french .
Uses Java class URLEncoder .
Parameters
Parameters
Attribute
Description
Required
String to encode String to encode in URL encoded chars. Yes
FileToString
The FileToString function can be used to read an entire file. Each time it is called it reads the
entire file.
If an error occurs opening or reading the file, then the function returns the string "**ERR**"
Parameters
Attribute
Description
Required
Path to the file name. (The path can be relative to the JMeter
Yes
File Name
launch directory)
File encoding if not the The encoding to be used to read the file. If not specified, the
No
platform default
platform default is used.
A reference name - refName - for reusing the value created by
Variable Name
No
this function. Stored values are of the form ${refName}.
The file name, encoding and reference name parameters are resolved every time the function is
executed.
samplerName
The samplerName function returns the name (i.e. label) of the current sampler.
The function does not work in Test elements that don't have an associated sampler. For example
the Test Plan. Configuration elements also don't have an associated sampler. However some
Configuration elements are referenced directly by samplers, such as the HTTP Header Manager
www.vskills.in
Page 125

and Http Cookie Manager, and in this case the functions are resolved in the context of the Http
Sampler. Pre-Processors, Post-Processors and Assertions always have an associated Sampler.
Parameters
Attribute
Variable
Name
Description
Required
No
function. Stored values are of the form ${refName}.
TestPlanName
The TestPlanName function returns the name of the current test plan (can be used in Including
Plans to know the name of the calling test plan).
escapeOroRegexpChars
Function which escapes the ORO Regexp meta characters, it is the equivalent of \Q \E in Java
Regexp Engine.
For example, [^"].+? becomes: \[\^\"\]\.\+\? .
Uses Perl5Compiler#quotemeta(String) from ORO.
Parameters
Attribute
Description
Required
String
to
The string to be escaped.
Yes
escape
Variable
No
Name
function. Stored values are of the form ${refName}.
PrePre-defined Variables
Most variables are set by calling functions or by test elements such as User Defined Variables; in
which case the user has full control over the variable name that is used. However some variables
are defined internally by JMeter. These are listed below.
COOKIE_cookiename - contains the cookie value (see HTTP Cookie Manager )
JMeterThread.last_sample_ok - whether or not the last sample was OK - true/false. Note: this is
updated after PostProcessors and Assertions have been run.
START variables (see next section)
PrePre-defined Properties
The set of JMeter properties is initialised from the system properties defined when JMeter starts;
additional JMeter properties are defined in jmeter.properties, user.properties or on the command
line.
Some built-in properties are defined by JMeter. These are listed below. For convenience, the
START properties are also copied to variables with the same names.
START.MS - JMeter start time in milliseconds
START.YMD - JMeter start time as yyyyMMdd
START.HMS - JMeter start time as HHmmss
www.vskills.in
Page 126

TESTSTART.MS - test start time in milliseconds
Please note that the START variables / properties represent JMeter startup time, not the test start
time. They are mainly intended for use in file names etc.
www.vskills.in
Page 127
19. REGULAR EXPRESSIONS

19.1. Overview
JMeter includes the pattern matching software Apache Jakarta ORO
There is some documentation for this on the Jakarta web-site, for example a summary of the
pattern matching characters
There is also documentation on an older incarnation of the product at OROMatcher User's guide ,
which might prove useful.
The pattern matching is very similar to the pattern matching in Perl. A full installation of Perl will
include plenty of documentation on regular expressions - look for perlrequick, perlretut, perlre,
perlreref.
It is worth stressing the difference between "contains" and "matches", as used on the Response
Assertion test element:
"contains" means that the regular expression matched at least some part of the target, so
'alphabet' "contains" 'ph.b.' because the regular expression matches the substring 'phabe'.
"matches" means that the regular expression matched the whole target. So 'alphabet' is "matched"
by 'al.*t'.
In this case, it is equivalent to wrapping the regular expression in ^ and $, viz '^al.*t$'.
However, this is not always the case. For example, the regular expression 'alp|.lp.*' is "contained"
in 'alphabet', but does not match 'alphabet'.
Why? Because when the pattern matcher finds the sequence 'alp' in 'alphabet', it stops trying any
other combinations - and 'alp' is not the same as 'alphabet', as it does not include 'habet'.
Note: unlike Perl, there is no need to (i.e. do not) enclose the regular expression in //.
So how does one use the modifiers ismx etc if there is no trailing /? The solution is to use
extended regular expressions , i.e. /abc/i becomes (?i)abc. See alsoPlacement of modifiers below.
19.2. Examples
Extract single string
Suppose you want to match the following portion of a web-page:
name="file" value="readme.txt">
and you want to extract readme.txt .
A suitable regular expression would be:
name="file" value="(.+?)">
The special characters above are:
www.vskills.in
Page 128

( and ) - these enclose the portion of the match string to be returned
. - match any character
+ - one or more times
? - don't be greedy, i.e. stop when first match succeeds
Note: without the ?, the .+ would continue past the first "> until it found the last possible "> - which
is probably not what was intended.
Note: although the above expression works, it's more efficient to use the following expression:
name="file" value="([^"]+)"> where
[^"] - means match anything except "
In this case, the matching engine can stop looking as soon as it sees the first " , whereas in the
previous case the engine has to check that it has found "> rather than say " > .
Extract multiple strings

Suppose you want to match the following portion of a web-page:
name="file.name" value="readme.txt" and you want to extract bothfile.name and readme.txt
.
A suitable regular expression would be:
name="([^"]+)" value="([^"]+)"
This would create 2 groups, which could be used in the JMeter Regular Expression Extractor
template as $1$ and $2$.
The JMeter Regex Extractor saves the values of the groups in additional variables.
For example, assume:
Reference Name: MYREF
Regex: name="(.+?)" value="(.+?)"
Template: $1$$2$
The following variables would be set:
MYREF: file.namereadme.txt
MYREF_g0: name="file.name" value="readme.txt"
MYREF_g1: file.name
MYREF_g2: readme.txt
These variables can be referred to later on in the JMeter test plan, as ${MYREF}, ${MYREF_g1}
etc
www.vskills.in
Page 129

19.3. Line mode
The pattern matching behaves in various slightly different ways, depending on the setting of the
multi-line and single-line modifiers. Note that the single-line and multi-line operators have nothing
to do with each other; they can be specified independently.
SingleSingle-line mode
Single-line mode only affects how the '.' meta-character is interpreted.
Default behavior is that '.' matches any character except newline. In single-line mode, '.' also
matches newline.
MultiMulti-line mode
Multi-line mode only affects how the meta-characters '^' and '$' are interpreted.
Default behavior is that '^' and '$' only match at the very beginning and end of the string. When
Multi-line mode is used, the '^' metacharacter matches at the beginning of every line, and the '$'
metacharacter matches at the end of every line.
19.4. Meta characters

Regular expressions use certain characters as meta characters - these characters have a special
meaning to the RE engine. Such characters must be escaped by preceding them with \ (backslash)
in order to treat them as ordinary characters. Here is a list of the meta characters and their
meaning (please check the ORO documentation if in doubt).
( ) - grouping
[ ] - character classes
{ } - repetition
* + ? - repetition
. - wild-card character
\ - escape character
| - alternatives
^ $ - start and end of string or line
The following Perl5 extended regular expressions are supported by ORO.
(?#text)
An embedded comment causing text to be ignored.
(?:regexp)
Groups things like "()" but doesn't cause the group match to be saved.
(?=regexp)
A zero-width positive lookahead assertion. For example, \w+(?=\s) matches a word
followed by white space, without including white space in the MatchResult.
www.vskills.in
Page 130
(?!regexp)
A zero-width negative lookahead assertion. For example foo(?!bar) matches any occurrence
of "foo" that isn't followed by "bar". Remember that this is a zero-width assertion, which
means that a(?!b)d will match ad because a is followed by a character that is not b (the d)
and a d follows the zero-width assertion.
(?imsx)
One or more embedded pattern-match modifiers. i enables case insensitivity, m enables
multiline treatment of the input, s enables single line treatment of the input, and x enables
extended white space comments.
Note that (?<=regexp) - lookbehind - is not supported.
Placement of modifiers
Modifiers can be placed anywhere in the regex, and apply from that point onwards. [A bug in
ORO means that they cannot be used at the very end of the regex. However they would have no
effect there anyway.]
The single-line (?s) and multi-line (?m) modifiers are normally placed at the start of the regex.
The ignore-case modifier (?i) may be usefully applied to just part of a regex, for example:
Match ExAct case or (?i)ArBiTrARY(?-i) case
Testing Regular
Regular Expressions
Since JMeter 2.4, the listener View Results Tree include a RegExp Tester to test regular
expressions directly on sampler response data.
There is a demo applet for Apache JMeter ORO.
Another approach is to use a simple test plan to test the regular expressions. The Java Request
sampler can be used to generate a sample, or the HTTP Sampler can be used to load a file. Add a
Debug Sampler and a Tree View Listener and changes to the regular expression can be tested
quickly, without needing to access any external servers.
www.vskills.in
Page 131
20. HINTS AND TIPS

This section is a collection of various hints and tips that have been suggested by various questions
on the JMeter User list. If you don't find what you are looking for here, please check the JMeter
Wiki . Also, try search the JMeter User list; someone may well have already provided a solution.
Passing variables between threads

JMeter variables have thread scope. This is deliberate, so that threads can act independently.
However sometimes there is a need to pass variables between different threads, in the same or
different Thread Groups.
One way to do this is to use a property instead. Properties are shared between all JMeter threads,
so if one thread sets a property , another thread can read the updated value.
If there is a lot of information that needs to be passed between threads, then consider using a file.
For example you could use the Save Responses to a file listener or perhaps a BeanShell
PostProcessor in one thread, and read the file using the HTTP Sampler "file:" protocol, and extract
the information using a PostProcessor or BeanShell element.
If you can derive the data before starting the test, then it may well be better to store it in a file, read
it using CSV Dataset.
20.1. Enabling Debug logging

logging
Most test elements include debug logging. If running a test plan from the GUI, select the test
element and use the Help Menu to enable or disable logging. The Help Menu also has an option
to display the GUI and test element class names. You can use these to determine the correct
property setting to change the logging level.
It is sometimes very useful to see Log messages to debug dynamic scripting languages like
BeanShell or groovy used in JMeter. Since 2.6, you can view log messages directly in JMeter GUI,
to do so, use menu Options > Log Viewer, a log console will appear at the bottom of the interface.
Note that log messages are cleared each time you disable this option. By default this log console is
disabled, you can enable it by changing in jmeter.properties:
jmeter.loggerpanel.display=true
20.2. Searching
It is sometimes hard to find in a Test Plan tree and elements using a variable or containing a
certain URL or parameter. A new feature is now available since 2.6, you can access it in Menu
Search. It provides search with following options:
Case Sensitive : Makes search case sensitive
www.vskills.in
Page 132

Regexp : Is text to search a regexp, if so Regexp will be searched in Tree of components,
example "\btest\b" will match any component that contains test in searchable elements of the
component
Figure 1 - Search raw text in TreeView
Figure 2 - Result in TreeView
Figure 3 - Search Regexp in TreeView (in this example we search whole word)
www.vskills.in
Page 133
Figure 4 - Result in TreeView
www.vskills.in
Page 134

Vs-1120 Certified Jmeter Tester - Reading - Material

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Vs-1120 Certified Jmeter Tester - Reading - Material

Enviado por

Direitos autorais:

Formatos disponíveis

Certified Jmeter Tester

Intelligent Communication Systems India

JV of DSIIDC ( Govt of NCT Delhi) &

This document describes developing,

Certified - Jmeter Tester

Certified Jmeter Tester

Cubezoid Solutions Private Limited

Content, design, typesetting and published by Cubezoid Solutions Private Limited,

All rights reserved

Certified Jmeter Tester

2. Getting Started .......................................................................................................................... 8

3. Building a Test Plan................................................................................................................ 20

4. Elements of a Test Plan .......................................................................................................... 23

5. Building a Web Test Plan....................................................................................................... 33

Certified Jmeter Tester

6. Building an Advanced Web Test Plan .................................................................................. 40

7. Building a Database Test Plan ............................................................................................... 42

8. Building an FTP Test Plan ..................................................................................................... 47

9. Building an LDAP Test Plan.................................................................................................. 52

10. Building a WebService Test Plan ........................................................................................ 66

11. Building a JMS Point-to-Point Test Plan............................................................................ 70

12. Building a JMS Topic Test Plan .......................................................................................... 73

Certified Jmeter Tester

13. Building a Monitor Test Plan............................................................................................... 78

14. Introduction to listeners ....................................................................................................... 82

15. Remote Testing...................................................................................................................... 91

16. Best Practices......................................................................................................................... 97

Certified Jmeter Tester

18. Functions.............................................................................................................................. 106

19. Regular Expressions ........................................................................................................... 128

20. Hints and Tips ..................................................................................................................... 132

Certified Jmeter Tester

1.2. The Future

Certified Jmeter Tester

Create Test Plan from Template

Templates icon item

Certified Jmeter Tester

SAX XML Parser

Certified Jmeter Tester

Libraries for ActiveMQ JMS

Certified Jmeter Tester

2.4. Running JMeter

Certified Jmeter Tester

Note: JMeter will only find .jar files, not .zip.

Certified Jmeter Tester

Example : jmeter -H my.proxy.server -P 8000 -u username -a password -N localhost

Certified Jmeter Tester

Example : jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

Example : jmeter-server -H my.proxy.server -P 8000

Certified Jmeter Tester

Logging and error messages

Certified Jmeter Tester

Full list of commandcommand-line options

Certified Jmeter Tester

Certified Jmeter Tester

Certified Jmeter Tester

Certified Jmeter Tester

3. BUILDING A TEST PLAN

3.1. Adding and Removing Elements

3.2. Loading and Saving Elements

3.3. Configuring Tree Elements

3.4. Saving the Test Plan

Certified Jmeter Tester