Understanding Throughput Utilization

GoStress v1.1 introduced a new metric in the HTML report: throughput utilization. It appears when you set a rate limit with --rps, and it tells you something important: how close did you actually get to the throughput you asked for?

The Basic Formula

utilization = (observed_rps / configured_rps) × 100

If you set --rps 200 and the test achieves 150 requests per second, your utilization is 75%. The report shows this as both a number and a progress bar.

32%

Low Utilization

68%

Moderate

95%

On Target

Why Utilization Matters

Without utilization, you only know the raw RPS number. But raw RPS doesn't tell you whether you're limited by the server or limited by your configuration. Utilization bridges that gap.

Scenario: 32% Utilization

You configured --rps 200 but only hit 64 RPS. This means:

Your target server is responding slowly (high latency)
With 5 workers, requests take so long that the rate limiter can't queue fast enough
Increasing --c (concurrency) would likely increase utilization

Action: Increase concurrency or check if the server has rate limiting, connection limits, or high p99 latency that's bottlenecking throughput.

Scenario: 95% Utilization

You configured --rps 200 and hit 190 RPS. This means:

Your rate limiter is working correctly
The server can handle the load
The small gap (5%) is normal overhead from timer resolution and goroutine scheduling

Good sign: 90-100% utilization means your test is accurately shaping the load you intended. The server is responding fast enough to keep up.

Scenario: Over 100%

This shouldn't happen with a working rate limiter, but if it does, it usually means:

Burst traffic leaked through the limiter
Multiple workers sent requests simultaneously in the same tick window

Note: GoStress uses a token-bucket rate limiter. Brief bursts above the limit are expected with high concurrency. Sustained over-100% is a bug — please report it.

Tuning for Target Utilization

Here's a practical approach to hitting your target throughput:

Step 1: Start with no RPS limit

                gostress --url https://api.example.com --c 50 --d 30

                # Note the max RPS you achieve

                # Let's say it's 850 RPS

Step 2: Set RPS to 80% of max

                gostress --url https://api.example.com --c 50 --d 30 --rps 680

                # Target: 680 RPS, expect ~90%+ utilization

Step 3: Adjust concurrency if needed

If utilization is low, you may not have enough workers to keep the rate limiter fed. Increase --c until utilization reaches your target range.

RPS Limit	Workers	Utilization	Diagnosis
200	5	32%	Too few workers or slow server
200	20	94%	Well-shaped load
500	10	68%	Server struggling, check p99

When Utilization Doesn't Appear

If you don't see the utilization bar in your report, it means you didn't set --rps. Without a configured limit, there's nothing to measure against, so the metric is hidden. The report still shows your raw RPS in the KPI card and throughput section.

                # This shows utilization

                gostress --url https://api.example.com --rps 100 --formats html

                # This does NOT show utilization (no --rps)

                gostress --url https://api.example.com --formats html