In JMeter, which properties decide that reports show the 90th, 95th and 99th percentiles?

## The three keys ```properties # bin/jmeter.properties, shipped commented out #aggregate_rpt_pct1=90 #aggregate_rpt_pct2=95 #aggregate_rpt_pct3=99 ``` Each is a float between 0 and 100 read as a string and parsed, so fractional levels work: `aggregate_rpt_pct3=99.9` gives you a 99.9th percentile column. There are exactly three; there is no `pct4`, and no way to ask for a fourth percentile column without changing code. ## What they reach The `aggregate_rpt_` prefix undersells them. They are read by: - `StatGraphVisualizer` — the **Aggregate Graph** listener, and the **Aggregate Report** listener too, because `StatVisualizer` builds its table from `StatGraphVisualizer.createObjectTableModel()`; - `StatisticsSummaryConsumer` — the HTML dashboard's **Statistics** table; - `ResponseTimePercentilesOverTimeGraphConsumer` — the dashboard's percentiles-over-time series. (A fourth class, `ResponseTimePerSampleGraphConsumer`, reads the same keys but is dead code — its javadoc says "NOT USED FOR NOW as of 3.0", it is not registered in `bin/reportgenerator.properties`, and it reads them as an `int` at construction rather than into `static final` fields, so it renders nothing.) So the same three lines change what three surfaces compute. That is usually what you want, and it is worth stating explicitly when handing the change to someone who only looked at the dashboard. One surface they do **not** reach: the **Summary Report** listener has no percentile columns at all. It deliberately stores no individual samples so that it runs in constant memory, so there is nothing there for these properties to configure. ## When they are read All three hold them in `static final` fields, initialised when the class first loads. Practical consequences: 1. edit the properties file, then restart JMeter — a running instance will not pick the change up; 2. the JVM that **generates the report** needs the properties, which is not necessarily the injector that ran the test; 3. a report regenerated later from a saved JTL uses whatever the properties say *at regeneration time*, not what they said during the run. There is a small internal asymmetry worth knowing but not worrying about: the GUI path divides the value by 100 before calling `getPercentPoint`, while the report generator passes it through as a 0-to-100 index. You still write `90` in both cases. ## Choosing a level, and what comes with it Moving to a deeper tail level interacts with the other two settings this leaf covers: - the deeper the level, the fewer samples sit above it, and the more the choice between `LEGACY` and `R_3` in `backend_metrics_percentile_estimator` can move the printed figure; - the level is read off whatever is inside the dashboard's percentile window, so `jmeter.reportgenerator.statistic_window` decides which samples a 99.9th percentile is even drawn from. In other words, changing `aggregate_rpt_pct3` to `99.9` is one line, but the number it produces is only as meaningful as the estimator and window behind it. ## Checking you got it After a restart, the column headers themselves tell you: the dashboard's Statistics table and the GUI listener both label the columns from these values, and the dashboard's percentile graph series are named from them too. If the headers still read 90/95/99, the properties file JMeter actually loaded is not the one you edited.