Skip to content
docs

Engine Health Monitoring

What the Engine Health tab shows

Section titled “What the Engine Health tab shows”

When you run a JMeter test on LoadFocus, the Engine Health tab of the result page shows how busy the load generators (the machines that send the traffic) were. If a generator runs out of CPU or memory, your response times get worse because of the generator, not because of your application, so check this tab before you trust a slow result.

Engine Health Example

Each generator reports about every 30 seconds, so the charts are coarse: a burst shorter than that can be missed. Two charts are shown:

  • CPU & Memory (%): CPU load of the whole generator machine, and the share of its physical memory in use. These are machine-wide figures, not just the JMeter process.
  • Network & Disk I/O (KB/s): data sent plus received over the network (loopback excluded), and data read plus written on the machine's disks.

Where to find it

Section titled “Where to find it”
  1. Open the result of a JMeter test run.
  2. Click the Engine Health tab. While the test runs, the charts keep updating.
  3. By default the charts combine all generators: CPU and memory are averaged, network and disk are summed. Click View per location to see each location separately, and View combined to go back.
  4. Hover over a point to see the exact value and time.

If the tab says "Engine health metrics not available for current test", no metrics were received for that run.

How to read it

Section titled “How to read it”
  • CPU or memory near 100%: the generators were saturated and may have slowed the load they send. Spread the same virtual users over more locations, or lower the virtual users per location, and run again. The load generator saturation guide explains the matching warning on the Overview.
  • Network spikes: usually large responses or downloads in your script.
  • Disk spikes: usually heavy logging or large result files written by the script.
  • Flat, low lines: the generators had headroom, so slow responses came from the system under test.

Good practice

Section titled “Good practice”
  • Run a small pilot test first and note the generator figures, then scale up.
  • Compare a response-time rise on the timeline with the same moment on Engine Health before blaming the application.
  • Keep script logging low; verbose logging adds disk and CPU load on the generator.