Execution Order #

Perhaps one of the most common problems in JMeter is a lack of knowledge of the execution order. This is especially common when trying to obtain specific results per thread or group of threads. First, we must understand that JMeter executes the test plan or script sequentially, but within this sequence, there is an order and hierarchy that is respected in the form of a tree.

The execution order can be found in this reference, section 3.9 and is as follows:

1. Configuration Elements
2. Pre-Processors
3. Timers
4. Samplers
5. Post-Processors (unless the response is null)
6. Assertions (unless the response is null)
7. Receivers (unless the response is null)

1.- Configuration Elements #

This means that first any configuration element at the test plan or test plan level will be executed, and similarly as the sequence descends through the lower levels of the tree.

2.- Pre-Processors #

Secondly, the pre-processors will be executed, although these are usually linked to a sampler because they expand or modify its scope.

3.- Timers #

Thirdly we have timers, and I dedicate a full paragraph to this because it is very common to find a test plan with more than one timer. While it is feasible or possible to have multiple timers, it is not recommended to have them at the same level. If you want a timer to affect only one sampler, the sampler must be at a level below it. If one or more timers are at the same level, these times will add up and could seriously affect your results.

4.- Samplers #

In fourth place, we have the samplers, and this is where we start to see results in the receivers, since these are the requests we send to the servers using the selected protocol.

5.- Post-Processors #

In fifth position are the post-processors. From this position on, the sampler must provide some output data; if it is null, the sampler will likely fail. All the extractors used to perform the correlations are located here, as they require information to extract the values hat will be used later.

6.- Assertions #

Once the required information has been extracted, the sixth and penultimate position are executed: the assertions. These are used to validate the received response by searching for specific values within it and acting upon them.

7.- Receivers #

In seventh and last place are the receivers, where we can view requests and responses. The most useful receiver for this is the view results tree.

It is very important to become familiar with and understand this execution sequence, because it will be repeated at each level of the tree. Some components inherit their values from lower levels, such as timers, which impact samplers at all their sublevels, as we can see in the following image:

In the previous example we only have one timer at the thread group level, this will not only affect the HTTP request samplers 1, 4, 5, “Debug” and “JSR223”, it will also impact the HTTP request samplers 2 and 3 that are within the “Transaction Controller”, it is easy to corroborate this because in the red box we can see the total execution time which is 36 seconds, and the timer was configured to 5 seconds, which was invoked by the 7 samplers giving a total of 35 seconds of waiting + 1 second of response times.

No matter how many sublevels there are, timers will always inherit their values. Another couple of examples of inheritance would be the HTTP Header Manager and the HTTP Request Defaults. In the case of the header manager, we could place a single component at the test plan level that would affect all thread groups so that they would use a single User-Agent value for all HTTP or HTTPS requests. Similarly, the request by definition will substitute the protocol and/or IP address and/or server name and/or port values ​​that will be used in all HTTP requests, as long as they are empty in the HTTP samplers.

In the future, I will create a post specifically to discuss the advantages of using inheritance in more detail, especially for reusing scripts in different testing environments.