wang-jiahua commented on PR #10444: URL: https://github.com/apache/rocketmq/pull/10444#issuecomment-5276027663
## Re-validated on a Fresh Environment (2026-08-13) Independent re-run after the June measurement, on newly provisioned hardware. **Environment**: `ecs.g7.2xlarge` (8C32G) broker with a 500GB ESSD PL1 store mounted `data=writeback`, separate producer host, Dragonwell 21.0.11, 1KB messages, sync send, 256 threads, store wiped and broker restarted per run. Baseline is develop `e3458616d`. ### Broker Young GC, three independent runs | Run | develop | this PR | Delta | |---|---|---|---| | 1 | 94 | 76 | -19.1% | | 2 | 92 | 74 | -19.6% | | 3 | 88 | 72 | -18.2% | ### Latency, 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 | 144236 | 1.54 | 2.54 | **5.55** | **11.71** | 350.67 | Milliseconds. Broker-side Young GC drops about 18-19% and reproduces across three independent runs, which is the signal I would rely on here; it lines up with the properties encode/decode path being the allocation source. P99 and P999 improve 5.3% and 9.6%, TPS is up 1.8%. Two things worth being explicit about. Send TPS is essentially flat in the earlier runs, and that is not a regression: this broker tops out near 160k TPS on the CommitLog append lock at about 69% CPU, so throughput here is lock-bound rather than allocation-bound. I also measured producer-side Young GC to see whether the client half of the change shows up, and it stayed at 26 for both develop and this PR - the message body allocation dominates on the client, so nothing is visible at that granularity. The measurable benefit of this PR is on the broker. -- 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]
