Which settings answer which question. The same metric gives different, equally valid answers depending on the DPS choices:
- the Metric type: which number of a point is read
- the Values filtering: which points are kept
- the Time period selector: which period is evaluated
- the Reduce: how series and points are combined
- the Resample: how points are merged over time
| Question | Metric type | Reduce | Resample |
|---|---|---|---|
| Response time of a typical call, or of a typical agent? | VALUE | Merged series, Average weighted or Average | optional |
| Total time spent in calls | VALUE | Merged series, Sum weighted | optional |
| CPU used on a host by its processes | VALUE | Merged series, Sum ¹ | e.g. 15 min windows |
| Total responses | VALUE or COUNT | Merged series, Sum | e.g. 1 min windows |
| Highest GC level per agent | VALUE | One per series, Plateau detection max | no effect |
| Scheduled tasks running at the same time | MAX or VALUE | Merged series, Count series | e.g. 15 min windows |
| Busy period of a mostly idle CPU | VALUE | One per series, Plateau detection max | no effect |
Values measured on a test environment unless stated otherwise.
¹ Approximate: a process present for part of an interval counts for the whole interval, see A task starting in the middle of an interval.
Response time per call or per agent
Two agents report Average Response Time (ms) for the same 15 s interval:
| Agent | Average response time | Calls (count) |
|---|---|---|
| A | 100 ms | 1000 |
| B | 2000 ms | 1 |
| Reduce function | Result | Question answered |
|---|---|---|
| Average | (100 + 2000) / 2 = 1050 ms | How fast is a typical agent? Each agent counts once: useful to compare agents or to spot a sick one. |
| Average weighted | (100 × 1000 + 2000 × 1) / 1001 = 101.9 ms | How fast is a typical call? Each call counts once: what users experience. |
- both are correct, they answer different questions
- Average weighted only compares like with like: the count is a number of calls for a response time, of samples for a percentage, of events for a counter. On counters, plain Average applies.
- over time, resample merges each kind its own way: see the resample table
Total time spent in calls
Same two agents. Sum weighted adds average × calls, the time spent in all the calls:
| Agent | Average response time | Calls | Average × calls |
|---|---|---|---|
| A | 100 ms | 1000 | 100,000 ms |
| B | 2000 ms | 1 | 2,000 ms |
| Sum weighted (Merged series) | 102,000 ms = 102 s |
- the merged series is resampled as a sum: a 1 min window gives the time spent in the calls of that minute
- on a percentage or a counter, the result has no meaning: the editor preview warns
CPU used on a host by its processes
CPU:Utilization % (process) is the share of the whole machine used by one JVM. Merged series with
Sum adds the processes at each 15 s interval, an absent process adding nothing:
| Interval | 10:00:15 | 10:00:30 | 10:00:45 | 10:01:00 | 1 min window |
|---|---|---|---|---|---|
| DataServer (count 6) | 15 | 16 | 14 | 15 | |
| Scheduled task, runs 30 s (count 6) | — | 30 | 20 | — | |
| Sum (Merged series) | 15 | 46 | 34 | 15 | (15 + 46 + 34 + 15) / 4 = 27.5 % |
- each merged point carries the highest count (6), so the window average weighs every interval alike
- the task weighs (30 + 20) / 4 = 12.5 %, its share of the minute
- carrying the sum of the counts instead (12 where the task ran) would weigh those intervals twice: 31.7 %
- a process present for part of an interval is added as if it ran the whole interval: see the two limits below
Sum, not Sum weighted: on a percentage, Sum weighted gives percent × samples. At 10:00:30:
| Reduce function | Formula | Result | Host CPU? |
|---|---|---|---|
| Sum | 16 + 30 | 46 % | yes |
| Sum weighted | 16 × 6 + 30 × 6 | 276 | no: percent × samples |
| Sum weighted / full count | 276 / 6 | 46 % | yes, exact on partial intervals too, not possible yet in DPS (clocked metric) |
Limit: a task starting in the middle of an interval
CPU percentages are clocked (6 samples per 15 s): a task starting halfway through an interval reports 3 samples there.
| Interval | 10:00:15 | 10:00:30 | 30 s window |
|---|---|---|---|
| DataServer (count 6) | 15 | 15 | 15 |
| Batch | 30 (count 3) | 30 (count 6) | |
| Sum (Merged series) | 45 | 45 | 45 % |
| Batch’s share of the time | 30 × 3/6 = 15 | 30 | 22.5 |
| Host CPU with that share | 30 | 45 | 37.5 % |
- Sum counts the batch for the whole first interval: 45 % instead of 37.5 %
- the share of time of each process is returned by the External API, Process CPU
Limit: a task reporting a single sample
Short scheduled tasks often run for one sample only (on the test environment, one task ran 18 times in 6 hours with a single sample each time):
| Interval | 10:00:15 |
|---|---|
| DataServer (count 6) | 15 |
| Task, one sample (count 1) | 36 |
| Sum (Merged series) | 51 % |
| Task’s share of the time | 36 × 1/6 = 6 |
| Host CPU with that share | 21 % |
- over a 15 min window (60 intervals), this one sample adds 36 / 60 = 0.6 % instead of 6 / 60 = 0.1 %
Why not average each process first
Averaging each process over the window, then adding the processes, ignores the time a process did not exist. Same data as CPU used on a host by its processes:
| Process | Average of its own points | Share of the minute |
|---|---|---|
| DataServer | (15 + 16 + 14 + 15) / 4 = 15 | 15 |
| Scheduled task | (30 + 20) / 2 = 25 | (30 + 20) / 4 = 12.5 |
| Added up | 40 % | 27.5 % |
- on a real batch window (8 October 2026, 18:30 → 18:45, 14 short scheduled tasks), the per-process averages of a 15 min window added up to 490 % of a host whose real CPU was 30 %
- merging first (Merged series, Sum), then resampling, avoids it
Total responses
Responses Per Interval counts the responses of each 15 s interval: its value and its count are the
same number.
| Interval | 10:00:15 | 10:00:30 | 10:00:45 | 10:01:00 | 1 min window |
|---|---|---|---|---|---|
| Agent 1 | 10 | 15 | 30 | 20 | |
| Agent 2 | 5 | 5 | 10 | 0 | |
| Sum (Merged series) | 15 | 20 | 40 | 20 | 15 + 20 + 40 + 20 = 95 |
- an interval counter is added up over time: the result grows with the window width
- metric type VALUE or COUNT give the same result
- Effective metric only does not change it: the intervals it removes hold zero
Highest GC level per agent
For every agent of an environment, the highest level of garbage collection it held for a while, and when, rather than a single peak.
| Field | Value |
|---|---|
| Agent | .*|<environment>|.* |
| Metric name | GC Monitor:Percentage of Time Spent in GC during last 15 minutes |
| Metric type | VALUE |
| Reduce scope / Reduce function | One per series / Plateau detection max |
- one row per agent: the plateau level, dated at its start
- a single high point does not make a plateau: the level must hold for 5 min (period of 2 h or less) or 15 min (longer period), see Plateau detection
- an agent without a plateau in the period is left out
- Max instead gives the single highest point of each agent
Scheduled tasks running at the same time
Each scheduled task reports CPU:Utilization % (process) only while it runs. Merged series with
Count series gives, at each interval, the number of tasks with a point there:
| Interval | 10:00:15 | 10:00:30 | 10:00:45 | 45 s window |
|---|---|---|---|---|
| Task A (count) | 6 | 6 | 6 | |
| Task B (count), stops mid-interval | 6 | 3 | — | |
| Count series (Merged series) | 2 | 2 | 1 | 1.67 (VALUE) / 2 (MAX) |
- a task stopping in the middle of an interval still counts 1 there
- with metric type VALUE, the window averages the numbers of tasks: (2 + 2 + 1) / 3 = 1.67
- with metric type MAX, it keeps the peak number of tasks running together: 2
Busy period of a mostly idle CPU
A DataServer is idle most of the time and busy for short stretches. The longest stable stretch is idle; the question is the level it holds when busy. Plateau detection max finds it (plateau detection).
Measured on hex-perf20 DataServer, CPU:Utilization % (process), 21 October 2026 10:00 → 14:00:
| Points of the period | Share |
|---|---|
| idle, 0 to 3 % | 18 % |
| normal load, 4 to 17 % | 62 % |
| busy, 18 % and more | 20 % |
| Result | Value | Stretch |
|---|---|---|
| Highest 15 min window | 21 % | 11:29 → 11:44 |
| Plateau detection max (window extended within 10 %) | 18 % | 11:17 → 11:47 |
- the window is 15 min because the period is longer than 2 h
- resample has no effect: One per series gives one value per series