This guide covers advanced options for controlling how burl runs benchmarks.
Use -q or --qps to limit requests per second:
# Maximum 100 requests per second
burl https://api.example.com -q 100 -c 10 -d 60s
This is useful for:
The QPS limit is distributed across all connections. With -q 100 -c 10, each connection averages 10 requests/second.
By default, burl uses HTTP/2 when available. You can force a specific version:
burl https://api.example.com --http1
Use this when:
burl https://api.example.com --http2
burl https://api.example.com --http3
HTTP/3 support is experimental and may not work with all servers.
The -w or --warmup flag sends requests that aren't counted in statistics:
# 50 warmup requests
burl https://api.example.com -w 50 -d 30s
| Scenario | Recommended Warmup |
|---|---|
| Quick test | 5-10 requests |
| Standard benchmark | 50-100 requests |
| Production testing | 100-500 requests |
| Cold start testing | 0 (no warmup) |
For realistic production testing, combine multiple options:
burl https://api.example.com/users \
-c 100 \ # 100 concurrent users
-d 5m \ # Run for 5 minutes
-q 500 \ # Limit to 500 req/s
-w 200 \ # 200 warmup requests
--http2 # Force HTTP/2
After running with these options, pay attention to:
| Metric | What to Look For |
|---|---|
| Requests/sec | Should be close to your QPS limit if set |
| P99 Latency | Critical for SLA compliance |
| Error Rate | Should be 0% under normal load |
| Throughput | Bytes/second transferred |
Latency
P50: 12.4ms ← Median - typical response time
P90: 32.1ms ← 90th percentile
P95: 45.2ms ← 95th percentile
P99: 89.3ms ← 99th percentile - tail latency
A large gap between P50 and P99 indicates inconsistent performance: