In JMeter's dashboard APDEX table, what do the T and F columns hold?

The APDEX panel sits on the left of the dashboard's index page, beside the Requests Summary pie and directly under the Test and Report information block. It is small, four columns wide, and it is the one table in the report whose column headings actively mislead. ## The two properties behind the two columns `ApdexSummaryConsumer` emits the columns in this order: | Column heading | Filled from | Default | |---|---|---| | `Apdex` | the computed score, to three decimals | — | | `T (Toleration threshold)` | `jmeter.reportgenerator.apdex_satisfied_threshold` | `500` ms | | `F (Frustration threshold)` | `jmeter.reportgenerator.apdex_tolerated_threshold` | `1500` ms | | `Label` | the sample label, or `Total` | — | The mismatch is real and it is the thing people get wrong out loud: the column called **Toleration** carries the **satisfied** threshold, and the column called **Frustration** carries the **tolerated** threshold. Read them positionally — `T` is the smaller number, `F` the larger — and remember both are milliseconds, never seconds. ## How JMeter builds the score For each label the consumer keeps three counters and computes: ``` apdex = (satisfiedCount + toleratedCount / 2) / totalCount ``` The counters are filled per sample, in this order: 1. Every sample under the label increments `totalCount` — **including failed ones**. 2. Only if the sample's success flag is true is its elapsed time examined at all. 3. Elapsed time at or under `T` increments `satisfiedCount`; otherwise, elapsed time at or under `F` increments `toleratedCount`; anything slower increments neither. Two consequences follow directly. A failing run is punished twice — once in the Statistics table's `Error %`, and again here, because failures enlarge the denominator while contributing nothing to the numerator. And a label whose samples are all slower than `F` scores exactly `0.000` even though every one of them succeeded. Samples produced by an empty Transaction Controller are skipped before any of this, so a controller that wrapped nothing cannot drag a score down. ## Per-transaction thresholds One global pair rarely fits a plan that mixes a search box with a nightly export. `jmeter.reportgenerator.apdex_per_transaction` sets a pair per label: - the format is `name:satisfiedMs|toleratedMs`, entries separated by `;` - `name` may be a literal label or a regular expression, and it must match the **whole** label, not part of it - exactly one matching entry is applied, but which one is unspecified when several patterns match: the entries are held in a `HashMap`, so the winner is not necessarily the one written first — keep the patterns non-overlapping. A label matching nothing keeps the global pair. - a chunk missing its colon or its pipe is logged as an error and ignored, leaving that label on the defaults The `Total` row is deliberately exempt: it is computed with `null` as the sample name, which matches no pattern, so it always uses the global `T` and `F`. That means the `Total` Apdex and a per-transaction Apdex in the same table can be scored against different bounds. ## Reading the table - The table is sorted by the `Apdex` column ascending by default, so the worst-scoring labels are the ones at the top — below the `Total` row, which sits in its own unsortable body above them and never moves. - The score is printed to three decimals; `T` and `F` are rendered as durations. - A score alone tells you nothing without its `T` and `F`, which is exactly why JMeter prints all three on the same row — quote them together or not at all. The same two thresholds are reused elsewhere in the report: the **Synthetic Response Times Distribution** graph takes its satisfied and tolerated boundaries from these very properties, so changing them redraws that graph's buckets as well as re-scoring this table. It is the one place in the dashboard where an APDEX setting has a visible effect outside the APDEX panel.