A JMeter run's summariser rate flattens while its Active count keeps climbing. Which JMeter output records that?

## What the console is actually showing you During a ramp, JMeter's summariser gives you two independent series on the same `+` line: a **rate** measured from completed samples, and a **thread count** taken from the engine's own counters. They move for different reasons, so a run where one flattens while the other climbs is a run where those two series have come apart. Read the sample output above column by column: - **`140.0/s` then `142.0/s` then `139.7/s`** — the delta rate, samples in that window divided by the window's span. Flat to within noise. - **`Active: 200` then `400` then `600`** — threads started and not yet finished, counted across every thread group in the engine. Tripled. - **`Avg: 340` then `690` then `1410`** — mean sample elapsed time in milliseconds. Roughly tracking the thread count. - **`Err: 0 (0.00%)`** — nothing has failed yet, so the flat rate is not being propped up by fast failures. ## The two rate figures are not interchangeable The last `=` total line in the same block reads `140.2/s` over `00:03:04`. That is a cumulative average over the whole run, and it moves slowly by construction — after three minutes it will barely register a change that the `+` line shows immediately. **Quote the `+` line when you are describing the current rate**, and never mix the two in the same sentence. ## Comparing the rate against a configured target If the plan paces with a **Constant Throughput Timer**, its field is labelled *Target throughput (in samples per minute)*. The summariser prints samples per **second**. Comparing them means dividing the target by 60 first: a timer set to `12000` is asking for 200/s, so a `+` line stuck at `139.7/s` is a run that is not reaching its configured target. That gap is the evidence; what the timer does about being behind schedule belongs to the throughput-timer material, not here. ## The rest of JMeter's evidence surface Everything JMeter itself will tell you about this is in three places: 1. **The console / `System.out` stream** — the `+` and `=` lines, controlled by `summariser.out`. 2. **`jmeter.log`** — the same lines timestamped if `summariser.log` is on, plus anything the engine logged at `INFO` or above. `Thread is done:`, `Thread finished:` and any `ERROR` entry live here. 3. **A gap in the lines themselves.** The summariser is driven by arriving samples, so a stretch of console with no line at all is a period in which nothing completed near a reporting boundary. There is no fourth place. Apache JMeter 6 ships **no listener that reports the injector host's own CPU or memory while a test runs** — the Monitor Results listener was dropped years ago — so `Active`, `Started` and `Finished` are the only host-side numbers that move during the run. `jmeter.log`'s startup block does print `os.name`/`os.arch`, `Max memory`, `Available Processors` and the local IP once, but that is the box's and the JVM's capacity, not what either did under load. GC pauses are only visible if the `VERBOSE_GC` line in `bin/jmeter` was uncommented before the run, and it ships commented out. ## What this evidence does not settle JMeter prints figures, not conclusions. A flat rate beside a rising `Active` count is consistent with more than one story, and the summariser has no opinion about which one applies to your run. Working out which side of the wire has run out of room, and what a defensible answer to that looks like, is a diagnostic exercise this material deliberately leaves alone. What you owe the diagnosis is an accurate reading of the lines: which rate figure you quoted, over which window, at what `Active` count, with what `Err` share, and whether `jmeter.log` carried anything at `ERROR` at the same timestamps.