The connection-pooled transport operates at 18x lower CPU utilization and maintains resident memory within 120 MB under peak load, compared to 816 MB in the baseline single-threaded runner.
Scaling worker concurrency from 1 to 4 sessions reduces overall sweep duration from 151 s down to 35 s. Concurrency beyond 8 worker sessions encounters host round-trip serialization and yields diminishing returns. Four worker threads is the recommended production setting.
| Workload scenario | Baseline | Direct serial | Optimized pool (2) | Optimized pool (4) | Optimized pool (8) |
|---|---|---|---|---|---|
| Sweep duration (wall s) | 2,772 | 151 | 78 | 35 | 32 |
| Processor time (CPU s) | 169.0 | 15.5 | 7.7 | 6.9 | 6.8 |
| Peak resident set (RSS MB) | 816 | 120 | 111 | 126 | 142 |
| Range scan duration (wall s) | 640 | 228 | 110 | 50 | 39 |
| Range peak memory (MB) | 1,436 | 297 | 245 | 223 | 289 |
baseline-single-thread (peak 816 MB)baseline-single-thread
pool-2-sessions (peak 111 MB)pool-2-sessions
pool-4-sessions (peak 126 MB)pool-4-sessions
pool-8-sessions (peak 142 MB)pool-8-sessions
pool-2, pool-4, pool-8 (mean 9.9, 19.7 and 21.3 %)pool-2 pool-4 pool-8
Throughput gains flatten beyond eight concurrent sessions. Two primary physical constraints set this ceiling:
Deploying four to six worker sessions captures 90% of maximum throughput while preserving minimal memory overhead.
python -m benchmark.runner --workload sweeps --pool 4 --output-dir ./results python -m benchmark.telemetry --input ./results/telemetry.json --export-svg