About

- Overview
- Changes
- Known Bugs
- License
- Contributors

Download

- Download Binary
- Download Source
- Nightly Builds

Documentation

- User Manual
- Javadocs
- Localisation (Translator's Guide)
- FAQ (Wiki)

JMeter Resources

- JMeter Wiki
- JMeter Articles
- JMeter on IRC
- Developer Notes

Tutorials

- Distributed Testing
- Recording Tests
- JUnit Sampler
- Access Log Sampler

Community

- Get Involved
- Mailing Lists
- SVN Repositories

16. Best Practices

16.1 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 gives makes JMeter work harder since it returns request quicker). The more JMeter works, the less accurate its timing information will be. 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.

16.2 Where to Put the Cookie Manager

> See Building a Web Test for information.

16.3 Where to Put the Authorization Manager

> See Building an Advanced Web Test for information.

16.4 Using the Proxy Server

> Refer to HTTP Proxy Server for details on setting up the proxy server. 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 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.yyy.com", then you can define a variable called "server" with the value of "xxx.yyy.com", and anyplace that value is found in your recorded samples will be replaced with "${server}".

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

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:

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

Copyright © 1999-2006, Apache Software Foundation