How to Get Started with JMeter: Part 3 – Reports & Performance Metrics Best Practices
For those of you just starting out with JMeter, we’ve put together a three part ‘how to’ series on how to use this powerful tool. (Note: if you’re already a JMeter pro, you might want to take a look at this webcast on creating advanced load testing scenarios)
This week we’ll focus on Reports & Performance Metrics and Best Practices, to make sure you test the best way possible.
Reports and Performance Metrics
After you run a test you want to see its results in a clear manner. The JMeter Aggregate Report Listener lets you see an overview of the summary statistics – ex.: the total number of requests executed, failures percentage, throughput in requests/time, and KB/second.
To use the Listener:
- Open the JMeter GUI
- Add the Aggregate Report Listener
- Click the Browse button and locate your .jtl test results file
A short and helpful explanation of Performance Metrics:
- Label – The sample label. If "Include group name in label?" is selected, the name of the thread group is added as a prefix. This allows identical labels from different thread groups to be collated separately, if required.
- # Samples - The number of samples with the same label
- Average - The average time of a set of results
- Median - The time in the middle of a set of results (i.e. 50% of the samples took no more than this time; the remainder took at least as long)
- 90% Line - 90% of the samples took no more than this time. The remaining samples at least as long as this.
- Min - The shortest time for the samples with the same label
- Max - The longest time for the samples with the same label
- Error % - The percentage of requests with errors
- Throughput - The Throughput is measured in requests per second/minute/ hour. The time unit is chosen so that the displayed rate is at least 1.0. When the throughput is saved to a CSV file, it is expressed in requests/second (e.g. 30.0 requests/minute is saved as 0.5).
- KB/Sec - The throughput measured in Kilobytes per second.
BlazeMeter also offers advanced Performance Metrics reports .
We recommend that while you load test, you ask yourself these questions
- What do you expect the average number of users (the normal load) to be?
- What is the peak number of users likely to be?
- What days and times should you load test your applications (e.g. if the testing crashes our servers, when will it affect the least number of people)?
- What are we trying to achieve?
Answering these questions will help you determine the test parameters and the best way to carry it out.
Last but not least, here are some final tips:
- Always Use the Latest JMeter Version
- Use the Correct Number of Threads
- Use the Non-GUI Mode to Run Large Scale Test
- Filter Out Irrelevant Requests When Using the HTTP(S) Test Script Recorder
- Include User Variables
- Reduce the Drain on Resources For example: use the non-GUI mode, use fewer Listeners, only use Listeners while scripting and debugging, use CSV output rather than XML, only save the data you need, and use as few Assertions as possible.
- Avoid Scripting Wherever Possible. Try using JMeter’s built-in test elements and functions. If you have to script, use the JSR223 test elements and the Groovy language.
- Parameterize Tests
- Don’t Modify the JMeter.properties File. Copy the property from jmeter.properties and modify its value in user.properties. This will make it easier for you to migrate to the next version of JMeter.
You are ready to go! If you have any questions or comments, please share in the comments box below.
Stay tuned with our blog to keep getting updates on JMeter. You are also welcome to check out our free online course for more JMeter training.
This blog post was originally published in 2017, and was updated for accuracy in 2019.