Throughput: Understanding RPS/TPS Metrics

zietho — Mon, 09 Mar 2026 10:02:49 GMT

Learn how to calculate and visualize throughput (Requests per Second / Transactions per Second) using Dynatrace metrics. This article explains which metrics to use, how RPS is derived, and how to build clean throughput tiles for performance and load-testing scenarios. It includes how to validate the math and common mistakes (rate vs count, aggregation, time buckets).

Throughput answers the “how many requests happened per unit time?” question. It is typically expressed as RPS (requests per second) or TPS (transactions per second). A closely related, and often more useful in practice, metric is the failure rate, which answers “how many requests fail per unit time?” or “what percentage fails?”. A metric you often see in SLO-style tiles.

In Dynatrace you can build these in two ways. Either via Explore metrics (Dashboards/Notebooks) with the built-in Rate and Interval controls. Or, in DQL timeseries command using the rate:… parameter inside the metric.
In the following sections we are going to look at both. To experience throughput first hand try the complementing examples on the Dynatrace playground dashboard within the "Throughput: Understanding RPS/TPS metrics" section.

Count vs Rate (and why labels go wrong)

Most “throughput confusion” is simply mixing these up:

Count per bucket: “requests per minute” that depends on the selected time bucket/interval.
Rate-normalized: “requests per second”, which is normalized to a duration, comparable across different intervals.

Dynatrace makes rate normalization explicit:

In Explore metrics, you can set Rate → Per second, Per minute, Per hour, Per day
In DQL, timeseries, you use the rate:1s parameter inside that divides by the interval to normalize to 1 second.

Build RSP/TPS tiles in Explore metrics in Dashboards or Notebooks

In a dashboard or notebook, select Add → Metrics.
Pick the relevant Service request count metric for your use case.
Use Filters to scope to the right services, endpoints, or environments.
Optional: use Split by to compare, for example, by endpoint, and Limit to keep charts readable.
Set Rate → Per second (this is your “RPS” switch)
Optionally set Interval to control time granularity; the interval defines the time slots used for aggregation.
And for a clear axis and chart legend, make sure that you set the unit to Count per second. Go to the Visual tab and into the unit surface to set it.

💡Dashboard hygiene tip: If you label the tile “RPS”, make sure Rate → Per second is set; otherwise, you’re showing “requests per bucket”.

Setting the unit:

Result (try it on this Dynatrace playground dashboard):

Failure throughput (failures/sec)

Same steps as above, but pick the failure count metric and set Rate → Per second.

Failure percentage

If you want “% failed”, compute it as Failure % = 100 × (failures / total requests).
In Explore, add the two metrics, Failures and Total requests, then create an Expression to calculate the percentage.

Building RPS metrics in DQL

Failure throughput per second (canonical example)

Dynatrace’s DQL examples show per-second failure rate for a specific endpoint using rate:1s (normalization):

timeseries sum(dt.service.request.failure_count, rate:1s),

filter:{startsWith(endpoint.name, "/api/accounts")}

❗Note: service metrics collect one-minute granularity request data and show per-minute counts by default, so rate:1s is what turns it into per-second. The rate parameter is formally defined as “divide by interval to normalize to a duration”.

Validate the math (quick sanity checks)

Do a “Interval scaling” test (catches 80% of mistakes)
1. Keep the same metric and filter.
2. Change Interval from (say) 1m → 5m.
3. If you’re charting counts, values should scale up (5x-ish).
4. If you’re charting rate-normalized RPS, values should be broadly stable.

Interval definition and behavior are documented in Explore metrics, and the link to DQL timeseries behavior is explicit.

Check the label correctness (“count/s” vs “requests per bucket”)

If your tile says “RPS/TPS”, ensure the rate is set in.

The data: either in Explore metrics (Rate → Per second) or DQL (rate:1s) is set.
The representation: unit is set to Count per second.

Common mistakes (and how to avoid them)

❌ Mistake: calling it “RPS” while charting per-minute counts
✅ Fix: use Rate → Per second (Explore) or rate:1s (DQL).
❌ Mistake: changing interval and thinking throughput “changed.”
✅ Fix: normalize to a rate; then interval changes mostly affect smoothness, not magnitude.
❌ Mistake: too many split series (“spaghetti chart”)
✅ Fix: filter tighter, then limit series.

Data Explorer (previous Dynatrace)

If you’re still doing throughput views in Data Explorer (previous Dynatrace), it also has a Rate control with Per second, Per minute, Per hour options. For details, refer to the official Data Explorer documentation about rate: https://docs.dynatrace.com/docs/shortlink/explorer#rate

topic Throughput: Understanding RPS/TPS Metrics in Dashboarding