Engine Health Report

The Engine Health report displays performance indicators received from the test engines (the infrastructure delivering the test traffic, not your system under test).

View Engine Health Report
CPU and Memory Levels
Troubleshooting High Levels of CPU and Memory
Reduce Number of Users per Engine
Video demo

The Engine Health report indicates whether the test infrastructure itself could be the cause of bottlenecks or the errors which are appearing in other reports. Engine Health is also a great resource when deciding how many virtual users (VUs) each engine can support. The ideal ratio depends on the complexity and memory footprint of your script(s). You can read about the process for planning and calibration of test execution to optimally utilize available resources in the help topic, Calibrating a BlazeMeter test.

When running performance tests, it is important to monitor the resource utilization. If one or more engines show high resource utilization, it could impact the test results.

The Engine Health report lets you view the following KPIs:

CPU
Represents the Percentage usage of CPU in instance
Memory
Represents the Percentage usage of the Virtual Memory in instance
Network I/O
Represents the amount of data transferred in I/O operations (KB/s)
Connections
Represents the number of persistent connections established for each transaction throughout the test

View Engine Health Report

Follow these steps:

In the Performance tab, select Reports. The most recent reports are shown on top.
Click Show all reports and select a report to view its details.

A test report overview opens.
Click the Engine Health tab.

A curve diagram appears, showing the level of resource utilization over the course of the associated tests:

To show/hide a KPI in the diagram, click the associated KPI label. For example, to hide Network I/O, click the Network I/O label in the X-axis.

CPU and Memory Levels

When conducting performance tests, it is recommended to maintain average CPU and memory usage below 70%. The thresholds for engine instances are set at 80% for CPU and 85% for memory. These averages are calculated using a 60-second moving average of the data points collected throughout the test duration.

To illustrate, let's consider a specific 60-second period within a test run, ranging from 1 minute and 20 seconds to 2 minutes and 20 seconds. In this interval, a total of 30 measurements are taken at 2-second intervals, divided into three sets of 10 consecutive measurements each. The first set averages 50%, the second 70%, and the third 90%. As a result, the 60-second moving average for this period amounts to 70%.

If the average of the 60-second moving averages recorded throughout the entire test duration surpasses the threshold set for a particular resource type (CPU or Memory), an on-screen alert will be displayed.

During run time, these alerts include a link to the Engine Health tab. You can use filters in this tab to detect engines with high levels of CPU or memory, streamlining the debugging process for more effectiveness.

To view only engines that exceeded 80% CPU usage, click High CPU
To view only engines that exceeded 85% memory usage, click High Memory

Troubleshooting High Levels of CPU and Memory

Ensure the following for optimal performance:

Verify that your script is resource-efficient, avoiding enabled listeners, redundant requests, or resource-intensive samplers such as the WebDriver sampler when possible.
Eliminate high-processing or infinite loops
Verify all CSV files are formatted correctly
Investigate time-outs, exceptions, and errors
Minimize the number of users per engine.
Consider adding more engines to enhance the test.

For more information on troubleshooting, see 3 Common Issues When Running JMeter Scripts and How to Solve Them.

Recommendations to Reduce Number of Users per Engine

This feature is exclusively available for Enterprise plans ("Unleashed"). Free, Basic, and Pro accounts do not have access to this feature. To upgrade, please contact your BlazeMeter account manager or send an email to sales@blazemeter.com.

Based on the test configuration, BlazeMeter monitors resource utilization at regular intervals. If the KPIs for CPU or memory usage exceed the thresholds over the duration of the test run, a warning is triggered:

This notification indicates that you should reduce the number of virtual users per engine for future test runs.

In the warning, click see recommendations.

The Usage Recommendations page displays:
Choose one of the following options:
- For JMX scripts, in the test row, click Apply.
  
  This action changes the Max Users per Engine value on the Test Configuration page according to the suggested value:
- For YAML scripts, edit the maximum number of users according to the suggested value on the Users per Engine Recommendations page:
  
  In YAML, the concept of a max users per engine value does not exist. Instead, a recommended value is provided on the Users per Engine Recommendations page. You need to ensure that none of the engines configured in the script exceed the recommended number of Virtual Users (VUs). Although this process is not as straightforward as with non-YAML scripts, it is typically an easy task.
  1. In the test row, click Edit YAML.
    
    The Test Configuration page opens.
  2. In the YAML script, check if a locations-weighted parameter is present and if not, add it. Ensure that locations-weighted is set to false:
```
locations-weighted: false
```
  3. Calculate the maximum users per engine using the following formula according to the suggested value on the Users per Engine Recommendations page:
    
    Engines Required = Concurrency / Recommended Maximum Users per Engine
    
    For example, if your test has a concurrency of 100 users and the recommendation is a maximum of 30 users per engine:
    
    Engines Required = 100 / 30 = 3.33 engines
    
    Round up the result to the nearest whole number which in this example is 4. This rounded-up value represents the total number of engines required for the specific scenario.
  4. Within your YAML script, divide the four engines among all required locations for the scenario. For example:
```
concurrency: 100
```
```
locations:
```
```
us-east4-a: 1
```
```
eu-west-1: 3
```
```
locations-weighted: false
```
  5. Save your YAML script.
  By following these steps, you can effectively modify your Taurus YAML test script when locations-weighted is set to false, ensuring that the maximum users per engine align with the recommended values while maintaining proper distribution across all locations.

Video demo

Learn how to prevent load engine overload and how BlazeMeter alerts you if issues arise.