wang-jiahua commented on PR #10526: URL: https://github.com/apache/rocketmq/pull/10526#issuecomment-5276027465
## Additional Benchmark: Consumer Path and Latency Percentiles (2026-08-13) Re-validated on a fresh environment. The June run above was **producer-only**, which turns out to understate this PR: the dispatch path it touches is barely exercised without a consumer attached. **Environment**: separate `ecs.g7.2xlarge` (8C32G) hosts for broker / producer / consumer, broker store on a 500GB ESSD PL1 mounted `data=writeback`, Dragonwell 21.0.11, 1KB messages, sync send, store wiped and broker restarted per branch. Baseline is develop `e3458616d`. ### Producer + consumer, 256 producer threads | Build | Send TPS | Consume TPS | Broker Young GC | |---|---|---|---| | develop | 112336 | 112791 | 116 | | this PR | 120825 | **173598** | 106 | ### Send latency, 256 threads, 90s, ~13M messages, 0 failures | Build | TPS | P50 | P90 | P99 | P999 | Max | |---|---|---|---|---|---|---| | develop | 141724 | 1.57 | 2.54 | 5.86 | 12.96 | 351.93 | | this PR | 144186 | 1.57 | 2.40 | **5.43** | 12.01 | 358.92 | Milliseconds, measured with per-thread 10us histograms merged at the end, so the instrumentation does not contend on the hot path. The consumer-attached number is the one I would weigh: consume TPS goes from 113k to 174k. Send-side P99 improves 7.3% and TPS 1.7%, which is a smaller and less certain effect - repeat runs on this setup move within roughly +/-6% on TPS, so I would treat the send-side figures as directional rather than proven. For completeness, producer-only on the same environment showed 160910 TPS against 159678 for develop, i.e. no meaningful difference. That is expected: with no consumer, `getMessage`/dispatch is idle, so the `List<Long>` to `long[]` and `DispatchRequest` reuse changes have almost nothing to act on. Worth stating plainly, since the earlier comment on this PR reported only that view. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
