query.response-time

The query.response-time domain includes query response time percentiles from MySQL 8.x Performance Schema table events_statements_histogram_global.

By default, this domain collects and reports the P999 (99.9th percentile) response time in microseconds.

To convert units, use the TransformMetrics plugin or write a custom sink.

Unlike other domains, all metrics are derived and specified as percentiles to collect, like:

level:
  freq: 5s
  collect:
    query.response-time:
      metrics:
        - p50
        - p95
        - p99

The example plan above collects the P50 (median), P95, and P99 query response time percentiles. The “p” prefix is required. The value after “p” is an integer between 1 and 999, inclusive. Blip creates and reports a derived metric for each, like:

p50 = 500
p95 = 7123
p99 = 9098

The true percentile might be slightly greater depending on how the histogram buckets are configured. For example, if collecting p95, the real percentile might be p95.8. See option real-percentiles.

For each configured percentile in the plan, Blip reports a corresponding pN metric where “N” is the collect (not real) percentile. See Usage above.

MySQL (and Percona Server) use histograms with variable bucket ranges. Therefore, the P99 might actually be P98.9 or P99.2. Meta key pN indicates the configured percentile, and its value pA indicates the actual percentile that was used.

Truncate performance_schema.events_statements_histogram_global after each collection. This resets percentile values so that each collection represents the global query response time during the collection interval rather than during the entire uptime of the MySQL. However, truncating the table interferes with other tools reading (or truncating) the table.

Sets @@session.lock_wait_timeout to avoid waiting too long when truncating performance_schema.events_statements_histogram_global. Has no effect when truncate-table = no.

Normally, truncating a table is nearly instantaneous, but metadata locks can block the operation.

None.

For example, if collecting P95, meta might contain p95 = p95.8: the real percentile is P95.8 because MySQL uses a fixed number of buckets to collect and calculate percentiles, and the bucket boundaires don’t line up pefectly.

Requires Performance Schema. See 29.1 Performance Schema Quick Start and related pages in the MySQL manual.