Which JMeter property selects the HTML report's percentile estimator, and what values does it take?

## The key itself ```properties # in bin/user.properties backend_metrics_percentile_estimator=R_3 ``` Three things about that line trip people up. - **The name is misleading.** The `backend_metrics_` prefix suggests it only concerns the Backend Listener, but the class that reads it, `org.apache.jmeter.report.processor.DescriptiveStatisticsFactory`, is what the HTML report generator uses too. One key, both surfaces. - **It takes no report-generator prefix.** Most report settings are `jmeter.reportgenerator.<something>`. The manual spells the exception out when it tells you to set `backend_metrics_percentile_estimator=R_3` "this time without any prefix". Writing `jmeter.reportgenerator.backend_metrics_percentile_estimator=R_3` sets a property nothing reads, and the run silently keeps the default. - **It is not in the shipped property file.** Grep `bin/jmeter.properties` for it and you get nothing; only `backend_metrics_window`, `backend_metrics_large_window` and `backend_metrics_window_mode` are there as commented examples. The estimator key exists in the code and in the manual, and you write it yourself. ## Accepted values The value is handed straight to `EstimationType.valueOf(...)`, the commons-math3 enum: | Value | Behaviour worth knowing | |---|---| | `LEGACY` | The default. Index `p x (N + 1)`, linear interpolation between neighbours. | | `R_3` | Index `rint(N x p)`, an integer, so an observed order statistic comes back. The value the manual names for lining the dashboard up with the Aggregate Report. | | `R_1`, `R_2`, `R_4` ... `R_9` | The rest of the Hyndman-and-Fan family commons-math3 implements; selectable, rarely selected. | Because `valueOf` is exact and case sensitive, `r_3`, `R3` and `R-3` are all rejected with an `IllegalArgumentException` out of the class initialiser rather than quietly falling back to `LEGACY`. Treat a bad value as a hard failure, not as a no-op — but not necessarily an early one. `DescriptiveStatisticsFactory` initialises lazily, on the first `PercentileAggregator` or Backend Listener metric built, so `-g` and a plan carrying a Backend Listener blow up within seconds, while a plain `-n ... -e` run finishes in full and only then raises `ExceptionInInitializerError` out of report generation. ## When it is read ```java private static final EstimationType ESTIMATION_TYPE = EstimationType .valueOf(JMeterUtils.getPropDefault("backend_metrics_percentile_estimator", "LEGACY")); ``` That is a `static final` initialiser. Practical consequences: 1. the property must be in place before the class loads — a properties file JMeter reads at startup, not something set from inside a plan; 2. it is one setting for the whole JVM, so a plan cannot use one estimator for one label and another elsewhere; 3. the JVM that **generates the report** is the one that has to carry the property, which matters when the report is produced from a saved JTL on a different machine from the injector. ## What it reaches Everything built through `DescriptiveStatisticsFactory`: - the report generator's `PercentileAggregator`, i.e. the dashboard's Median and its three percentile columns, plus the percentile graph series; - the Backend Listener's `SamplerMetric` and `UserMetric`, i.e. the percentiles streamed live to a metrics backend. So the property is not a report-only switch. Changing it to match the GUI listener also changes what a live dashboard has been showing, which is worth saying out loud before you push it to a shared install. ## What it does not reach The GUI **Aggregate Report** and **Aggregate Graph** never consult it — they go through `StatCalculator`, which has no pluggable estimator at all. There is no property that changes the listener's formula; the alignment is always done by moving the dashboard toward the listener, never the other way round.