Beruflich Dokumente
Kultur Dokumente
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 functional-testing
capabilities.
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, and JUnit.
2.1 Requirements
JMeter requires your computing environment meets some
minimum requirements.
2.2 Optional
If you plan on doing JMeter development or want to use Sun's
Java Standard Extension packages, then you will need one or
more optional packages listed below.
2.2.7 BeanShell
To run the BeanShell function or any of the BeanShell test
elements (sampler, timer etc), you need to download the
beanshell jar from http://www.beanshell.org/ and copy the jar
file to the jmeter/lib directory , where JMeter will
automatically pick it up.
2.2.7 Libraries for ActiveMQ 3.0
See http://activemq.apache.org/initial-configuration.html for
details.
2.3 Installation
Note: avoid installing JMeter in
a path with spaces in the name.
This causes problems for
remote testing.
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.
jakarta-jmeter-2.3.1
jakarta-jmeter-2.3.1/bin
jakarta-jmeter-2.3.1/docs
jakarta-jmeter-2.3.1/extras
jakarta-jmeter-2.3.1/lib/
jakarta-jmeter-2.3.1/lib/ext
jakarta-jmeter-2.3.1/lib/junit
jakarta-jmeter-2.3.1/printable_docs
There are some additional scripts in the bin directory that you
may find useful. Windows script files (the .CMD files require
Win2K or later):
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:
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.
-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
-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.
Parameters
Hierarchy
example
complex example
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.
4. Elements of a Test 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:
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).
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.
About Index Next Prev
• Overview
• Changes • 18.1 Samplers
• Known Bugs o FTP Request
• License o HTTP Request
• Contributors o JDBC Request
o Java Request
Download o SOAP/XML-RPC Request
o WebService(SOAP) Request
• Download o LDAP Request
Releases o LDAP Extended Request
• Developer o Access Log Sampler
(Nightly) o BeanShell Sampler
Builds o BSF Sampler
o TCP Sampler
Documentation o JMS Publisher
o JMS Subscriber
• User Manual o JMS Point-to-Point
• Javadocs o JUnit Request
• Localisation o Mail Reader Sampler
(Translator's o Test Action
Guide) • 18.2 Logic Controllers
• Building o Simple Controller
JMeter and o Loop Controller
Add-Ons
o Once Only Controller
• JMeter Wiki
o Interleave Controller
• FAQ (Wiki)
o Random Controller
o Random Order Controller
Tutorials (PDF
o Throughput Controller
format)
o Runtime Controller
o If Controller
• Distributed
o While Controller
Testing
• Recording o Switch Controller
Tests o ForEach Controller
• JUnit Sampler o Module Controller
• Access Log o Include Controller
Sampler o Transaction Controller
• Extending o Recording Controller
JMeter • 18.3 Listeners
o Sample Result Save Configuration
Community o Graph Full Results
o Graph Results
• Get Involved o Spline Visualizer
• Mailing Lists o Assertion Results
o View Results Tree
• SVN
Copyright © 1999-2008, Apache Software Foundation
Functions and Variables
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)}
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:
${VARIABLE}
If an undefined function or variable is referenced, JMeter does not report/log an error - the
reference is returned unchanged. For example if UNDEF is not defined as a variable, then
the value of ${UNDEF} is ${UNDEF}. Variables, functions (and properties) are all case-
sensitive. Versions of JMeter after 2.3.1 trim spaces from variable names before use, so for
example ${__Random(1,63, LOTTERY )} will use the variable 'LOTTERY' rather than '
LOTTERY '.
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.
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.
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
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"))}
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.
*
If you define a user-defined static variable with
the same name as a built-in function, your static
variable will override the built-in function.
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.
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.
19.5 Functions
19.5.1 __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
• An integer - Tells JMeter to use that match. '1' for the first found
match, '2' for the second, and so on
• RAND - Tells JMeter to choose a match at random.
Third No,
• ALL - Tells JMeter to use all matches, and create a template
argument default=1
string for each one and then append them all together. This
option is little used.
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.
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.
Regular Expressions
20.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 also Placement of modifiers
below.
20.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 reqular expression would be:
name="file" value="(.+?)"
Note: without the ?, the .+ would continue past the first " until it found the last possible " -
probably not what was intended.
• 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
Single-line mode
Default behaviour is that '.' matches any character except newline. In single-line mode, '.' also
matches newline.
Multi-line mode
Multi-line mode only affects how the meta-characters '^' and '$' are interpreted.
Default behaviour 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.
• ( ) - grouping
• [ ] - character classes
• { } - repetition
• * + ? - repetition
• . - wild-card character
• \ - escape character
• | - alternatives
• ^ $ - start and end of string or line
Please note that ORO does not support the \Q and \E meta-characters. [In other RE engines, these
can be used to quote a portion of an RE so that the meta-characters stand for themselves.]
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:
Glossary
Latency . JMeter measures the latency from just before sending the request to just after the first
response has been received. Thus the time includes all the processing needed to assemble the
request as well as assembling the response, which in general will be longer than one byte.
Protocol analysers (such as Wireshark) measure the time when bytes are actually sent/received
over the interface. The JMeter time should be closer to that which is experienced by a browser or
other application client.
Median is a number which divides the samples into two equal halves. Half of the samples are
smaller than the median, and half are larger. [Some samples may equal the median.] This is a
standard statistical measure. See, for example: Median entry at Wikipedia. The Median is the
same as the 50 th Percentile
90% Line (90 th Percentile) is the value below which 90% of the samples fall. The remaining
samples too at least as long as the value. This is a standard statistical measure. See, for example:
Percentile entry at Wikipedia.
Throughput is calculated as requests/unit of time. The time is calculated from the start of the
first sample to the end of the last sample. This includes any intervals between samples.