wang-jiahua opened a new pull request, #11006:
URL: https://github.com/apache/rocketmq/pull/11006
### Which Issue(s) This PR Fixes
Fixes #11002
### Brief Description
Two per-message `String.getBytes()` allocations on the broker write path are
avoided:
- `MessageExtEncoder`: the topic is re-encoded to UTF-8 bytes for every
message. The encoder instance is already `ThreadLocal`, so a single-slot
`cachedTopic`/`cachedTopicData` pair is safe without synchronization: a hit
returns the cached bytes; a miss falls back to `getBytes` and refreshes the
slot.
- `MessageDecoder.createCrc32()`: the constant property key `PROPERTY_CRC32`
is now pre-encoded into a `private static final byte[]`.
### How Did You Test This Change?
- Functional: `AppendCallbackTest` 4/4, `AppendPropCRCTest` 2/2 (covers the
CRC32 constant path), `LmqDispatchTest` 5/5, `CompactionLogTest` 4/4,
`MessageDecoderTest` 7/7; checkstyle clean.
- Microbenchmark on an 8C32G ECS (Dragonwell 21), 20M ops,
thread-allocated-bytes measured:
- baseline `getBytes`: 8.14 ns/op, 56 B/op
- cache hit (same topic, different String instance, `equals` path): 2.63
ns/op, 0 B/op
- worst case (two topics strictly alternating, equal length differing only
in the last char): 13.84 ns/op, 56 B/op — i.e. a miss costs one extra
`String.equals` (~5.7ns) on top of the original `getBytes`; the break-even hit
rate is ~51%, and per-thread broker traffic is typically far more repetitive
than that.
- End-to-end 4-node cluster A/B (256-thread sync producer, 1KB, per-arm
clean store + restart): broker TPS and young GC per million messages flat
versus baseline — the saving is below GC-count resolution at this load, so this
is a cleanup-level allocation reduction and is labeled as such.
--
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]
