wang-jiahua opened a new issue, #10982: URL: https://github.com/apache/rocketmq/issues/10982
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary Discussion: cache the serialized route data in NameServer's `getRouteInfoByTopic` instead of deep-copying and JSON-encoding the full route on every request. ### Motivation `ClientRequestProcessor#getRouteInfoByTopic` currently does two allocation-heavy steps per request: 1. `RouteInfoManager#pickupTopicRouteData` deep-copies the route under the read lock: a new `TopicRouteData`, a `LinkedList` of per-broker `BrokerData` clones, plus queue-data/filter-server containers. 2. `topicRouteData.encode(...)` serializes the copy to JSON. Clients poll routes periodically (30s by default), so with a few thousand clients this pair dominates NameServer allocation, and none of it changes between route updates — the same topic's route is re-copied and re-encoded thousands of times per registration epoch. ### Rough direction (for discussion) Cache the encoded `byte[]` per topic and invalidate on route mutation (register/unregister broker, topic config changes, broker liveness changes). Three parts make this non-trivial, which is why this is a discussion issue rather than a PR: - `orderTopicConf` is looked up from KV config and merged into the response at query time, so either the KV lookup stays outside the cache key or KV changes must also invalidate. - Requests are answered with two different JSON shapes (standard JSON for clients >= 4.9.4 or `acceptStandardJsonOnly`, the legacy fastjson shape otherwise), so the cache needs two variants per topic. - With `supportActingMaster` enabled the route is post-processed per request, which would have to move inside the cached computation or gate the cache. If maintainers see a simpler angle (e.g. caching only the deep copy and keeping per-request encoding, or a versioned copy-on-write route snapshot), happy to take that direction instead. I can follow up with an implementation and benchmark numbers once the approach is agreed. -- 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]
