Apache JMeter - User's Manual: Best Practices http://jmeter.apache.org/usermanual/best-practices.

html

Index Next Prev

About

Overview 16. Best Practices

Changes
Subscribe to What's New
Issues 16.1 Limit the Number of Threads
License
Contributors 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
Download
JMeter works, the less accurate its timing information may become. The more work JMeter does, the more each
Download Releases thread has to wait to get access to the CPU, the more inflated the timing information gets. If you need large-scale
Developer (Nightly) Builds 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
Documentation be used. It does not require any network access so can give some idea as to the maximum throughput achievable.

User Manual JMeter versions since 2.8 have an option to delay thread creation until the thread starts sampling, i.e. after any
Best Practices thread group delay and the ramp-up time for the thread itself. This allows for a very large total number of threads,
Component Reference provided that not too many are active concurrently.
Functions Reference
Javadocs
Localisation (Translator's Guide) 16.2 Where to Put the Cookie Manager
Building JMeter and Add-Ons
JMeter Wiki See Building a Web Test for information.
FAQ (Wiki)

Tutorials (PDF format)

16.3 Where to Put the Authorization Manager
Distributed Testing
Recording Tests See Building an Advanced Web Test for information.
JUnit Sampler
Access Log Sampler
Extending JMeter 16.4 Using the Proxy Server
Community
Refer to HTTP Proxy Server for details on setting up the proxy server. The most important thing to do is filter out all
Get Involved requests you aren't interested in. For instance, there's no point in recording image requests (JMeter can be instructed
Mailing Lists to download all images on a page - see HTTP Request ). These will just clutter your test plan. Most likely, there is an
SVN Repositories 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".
Foundation
Alternatively, you can exclude images by entering ".*\.gif" as an "Exclude Pattern". Depending on your application,
ASF this may or may not be a better way to go. You may also have to exclude stylesheets, javascript files, and other
Sponsorship included files. Test out your settings to verify you are recording what you want, and then erase and start fresh.
Thanks
The Proxy Server 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".

One of the most useful features of the Proxy Server 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 Variables
elements, 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}".

Please note that matching is case-sensitive.

If JMeter does not record any samples, check that the brower 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

1 of 4 9/3/2013 12:53 AM
Apache JMeter - User's Manual: Best Practices http://jmeter.apache.org/usermanual/best-practices.html

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. Or perhaps use the Access Log Sampler. [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
Only save the data that you need
Use as few Assertions as possible

If your test needs large amounts of data - particularly if it needs to be randomised - create the test data in a file that
can be read with CSV Dataset. This avoids wasting resources at run-time.

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.

There is no security. Anyone who can connect to the port

can issue any BeanShell commands. These can provide
unrestricted access to the JMeter application and the
host. Do not enable the server unless the ports are
protected against access, e.g. by a firewall.

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:

2 of 4 9/3/2013 12:53 AM
Apache JMeter - User's Manual: Best Practices http://jmeter.apache.org/usermanual/best-practices.html

java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60

16.8 BeanShell scripting

16.8.1 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.

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)

16.8.2 Sharing Variables

Variables can be defined in startup (initialisation) 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();
}
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 BSF (and BeanShell) samplers which
can be used instead.

Create a simple Test Plan containing the 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

3 of 4 9/3/2013 12:53 AM
Apache JMeter - User's Manual: Best Practices http://jmeter.apache.org/usermanual/best-practices.html

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.

16.11 JSR223 Elements

When using JSR 223 elements, prefer script file to inline script as JMeter will compile script (if underlying language
supports it) which will avoid parsing it each time it is executed and will highly improve performances of Test Plan.

In this case, don't use any User Defined variable or variable you create directly in the script file, instead pass these as
Parameters to the script and use them this way.

16.12 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

Index Next Prev

Copyright © 1999-2013, Apache Software Foundation

Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation.

4 of 4 9/3/2013 12:53 AM