In this entry, we present the best practices in JMeter proposed by two experts in the world of JMeter: Philippe Mouawad and Antonio Gómez Rodríguez. They are the authors of a book that, in my opinion, is one of the best currently: Master Apache JMeter From load testing to DevOps. I recommend the ebook. I have added comments and examples to expand or clarify some of the concepts.

Obsolete Documentation #

Given that JMeter has been available for many years, be careful when consulting blogs, videos, and other documentation. Any information published more or less two years ago, or referring to versions before 4.0, is likely outdated. The best practice is to consult the official documentation and the changes history through the different versions.

A significant source of information is our page in Spanish, JMeter in Spanish, on Slack and Facebook.

Performance #

The best practice is not to use BeanShell or JavaScript because they significantly degrade the performance of the tool. The best practice is to use JSR223 that uses Groovy as default. Groovy is a modern and powerful language that works with the latest versions of Java.

Use the Non-GUI mode #

The best practice is not to use the Non-GUI mode for load testing. The GUI mode should be used during the script development phase, but it is recommended to switch to the Non-GUI mode once this phase has been completed.

Report HTML #

JMeter provides many alternatives for graphing results in the GUI mode. However, best practice is to produce the HTML report at the end of the test run (in non-GUI mode):

jmeter -n -t [jmx file] -l [results file] -e -o [\Path to output folder]

I recommend viewing this link.

If for some reason there were a chart that wasn’t included in the HTML report, always have the option to load the results file in the GUI mode (after completing the test).

Never directly modify the XML file where JMeter stores the test (*.jmx file) #

The best practice is to never manipulate it.

Mastering the concept of execution order #

In brief, the execution order of elements in JMeter follows specific rules. Our esteemed colleague Antonio presents the details of execution order in this publication.

Variables and Properties #

The best practice is to clearly understand the differences between Variables and Properties. A Variable is a dynamic value that is exclusive to a thread or user virtual (VUser). Variables are usually defined using the element User-Defined Variables at the plan level during test execution. The thread makes a local copy of the variable, and can modify this value without affecting other threads in the test. This usage is typically limited to user data and correlation rules. Variables are accessed using ${varName}. Our experienced colleague Delvis illustrates how to use variables during correlation process in this publication.

Furthermore, a Property is a dynamic value that is common to all threads and normally used to define information related to the execution environment. You can access Properties using the function __P(). For example, the Property PropX will be read using ${__P(PropX)}

Usage of Functions #

JMeter provides a comprehensive list of functions that allow you to optimize the creation of scripts for tests. The best practice is to familiarize yourself with and use these functions rather than trying to “reinvent the wheel.” In this publication, our esteemed colleague Antonio presents some functions for specifying time values.

If this were not enough, JMeter also has another plugin that provides additional functions.

A common example is to use the UUID function to create a random email address directory of the following form:

{
    "email": "${__substring(${__UUID()}, 0, 8)}.${__substring(${__UUID()}, 25, 35)}@gmail.com", 
}

Open Models vs Closed Models #

The best practice is to use the correct model for the application being tested. In an open model, users arrive at the application asynchronously, independent of the number of transactions being processed in the SUT (system under test). The requirement here is the number of TPS (transactions per second) x unit-time.

An example typical of this type of testing are applications from e-commerce.

On the other hand, in a closed model, the number of users is fixed, so the number of transactions is limited by the amount of users in the system under test (SUT). A typical example is a call center where the number of accepted calls is limited by the number of operators; if all operators are busy, the system will not accept any more calls. The requirement here is the number of simultaneous users (VUsers).