JMeter Quick Reference - sonnettest/JMeter GitHub Wiki
HTTP Cookie Manager
add to each Thread Group in your test plan to ensure that each thread gets its own cookies, but shared across all HTTP Request objects.
HTTP Header Manager
lets you customize what information JMeter sends in the HTTP request header. 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 different HTTP Request objects in your test.
Handling User Sessions With URL Rewriting –
[Handling user sessions]
Reducing resource requirements
- 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
- 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-time.
Constant Throughput Timer
This timer introduces variable pauses, calculated to keep the total throughput (in terms of samples per minute) as close as possible to a give figure. Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it. N.B. although the Timer is called the Constant Throughput timer, the throughput value does not need to be constant. It can be defined in terms of a variable or function call, and the value can be changed during a test. The value can be changed in various ways:
- using a counter variable
- using a JavaScript or BeanShell function to provide a changing value
- using the remote BeanShell server to change a JMeter property
Calculation of throughput
- this thread only - each thread will try to maintain the target throughput. The overall throughput will be proportional to the number of active threads.
- all active threads in current thread group - the target throughput is divided amongst all the active threads in the group. Each thread will delay as needed, based on when it last ran.
- all active threads - the target throughput is divided amongst all the active threads in all Thread Groups. Each thread will delay as needed, based on when it last ran. In this case, each other Thread Group will need a Constant Throughput timer with the same settings.
- all active threads in current thread group (shared) - as above, but each thread is delayed based on when any thread in the group last ran.
- all active threads (shared) - as above; each thread is delayed based on when any thread last ran.
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
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");
Parameterizing 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.
Test Action
The Test Action sampler is a sampler that is intended for use in a conditional controller. Rather than generate a sample, the test element eithers pauses or stops the selected target. This sampler can also be useful in conjunction with the Transaction Controller, as it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child. The "Stop" action stops the thread or test after completing any samples that are in progress. The "Stop Now" action stops the test without waiting for samples to complete; it will interrupt any active samples. If some threads fail to stop within the 5 second time-limit, a message will be displayed in GUI mode. You can try using the Stop command to see if this will stop the threads, but if not, you should exit JMeter. In non-GUI mode, JMeter will exit if some threads fail to stop within the 5 second time limit. [This can be changed using the JMeter property jmeterengine.threadstop.wait ]
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.
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. 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.
Default Configuration
Refer - http://jmeter.apache.org/usermanual/listeners.html
Non-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. 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.
Remote Testing
http://jmeter.apache.org/usermanual/remote-test.html
__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 ${__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