Motivation
When running latency benchmarks — especially load tests with high concurrency — it's important to know whether the client machine itself is a bottleneck. High CPU usage, memory pressure, or network saturation on the client side can skew latency measurements without any visible errors.
Currently there's no built-in way to observe client-side resource usage during a run.
Proposed feature
Add an optional SystemMetricsMonitor callback that tracks CPU, memory, and network I/O while a benchmark runs. It should:
- Collect periodic samples of system resource usage during the run
- Contribute aggregated statistics (avg, p50, p90, p99, max) to
result.stats
- Show live metrics in the progress display during the run
- Persist metrics as part of
stats.json so they survive save/load round-trips
- Be optional (gated behind an extra dependency)
- Support both per-process and system-wide monitoring modes
Use cases
- Detecting whether the client machine is saturated during high-concurrency load tests
- Correlating network throughput with latency degradation
- Validating that benchmarks ran on a machine with sufficient headroom
- Comparing resource usage across different concurrency levels
Motivation
When running latency benchmarks — especially load tests with high concurrency — it's important to know whether the client machine itself is a bottleneck. High CPU usage, memory pressure, or network saturation on the client side can skew latency measurements without any visible errors.
Currently there's no built-in way to observe client-side resource usage during a run.
Proposed feature
Add an optional
SystemMetricsMonitorcallback that tracks CPU, memory, and network I/O while a benchmark runs. It should:result.statsstats.jsonso they survive save/load round-tripsUse cases