Fix #120: Async multi-threaded benchmark returns correct aggregated metrics

[mcurrier2]

Summary

• Fixes incorrect metrics when using --concurrency > 1 in async mode
• Multi-threaded one-way and round-trip functions now return the aggregated PerformanceMetrics directly from aggregate_worker_metrics(), instead of attempting to repopulate a shared MetricsCollector

Problem

When --concurrency > 1, the async benchmark runner had three compounding bugs:

1. Latency discarded: The repopulation loop called record_message(size, None) — the None latency meant all percentiles/min/max/mean from the correct aggregation were thrown away
2. Throughput 2x inflated: Two separate loops (one for latency samples, one for throughput messages) both called record_message, doubling the throughput counter
3. messages_per_worker unused: Computed and logged but never applied — each worker ran the full msg_count

Fix

Changed run_multi_threaded_one_way and run_multi_threaded_round_trip to:

• Return Result<PerformanceMetrics> instead of Result<()>
• Return the output of aggregate_worker_metrics() directly
• Remove the broken record_message repopulation loops
• Remove the unused metrics_collector parameter

The parent dispatch functions (run_one_way_test, run_round_trip_test) now use the returned aggregated metrics directly for the concurrency > 1 path.

Scope

This bug only affects async mode with --concurrency > 1 (not the default). Single-threaded paths and all blocking mode paths are unaffected.

Test plan

• cargo fmt — clean
• cargo clippy --all-targets -- -D warnings — zero warnings
• cargo test — all tests pass
• cargo build --release — clean build
• Pre-commit hooks pass

Closes #120

Made with Cursor

[coderabbitai]

Warning

Review limit reached

@mcurrier2, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 35 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 2830c920-f030-45fe-a593-07d084cb1412

📥 Commits

Reviewing files that changed from the base of the PR and between d586320 and 7307659.

📒 Files selected for processing (2)

• src/benchmark.rs
• src/ipc/shared_memory_blocking.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}