f1amingo opened a new issue, #10423: URL: https://github.com/apache/rocketmq/issues/10423
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary `LiteConsumerLagCalculator.getLagCountTopK` currently calls `getStoreTimestamp()` (disk I/O) for **every** offset entry during full-table traversal, creates a `LiteLagInfo` object for each entry regardless of whether it enters the topK heap, and uses `String.split()` for key parsing. These cause unnecessary overhead when the offset table is large. ### Motivation In production with thousands of lite topics per group, the current implementation issues N `getStoreTimestamp` calls (each hitting the message store), allocates N intermediate objects, and performs N string splits — but only K (topK, typically small) results are actually needed. This wastes CPU and I/O, especially under periodic metric collection. ### Describe the Solution You'd Like 1. **Defer `getStoreTimestamp` to topK results only**: Accumulate `consumerOffset` in `LiteLagInfo` during traversal, then compute timestamps for the final topK entries after heap filtering — reducing N expensive calls to K. 2. **Lazy object creation**: Only instantiate `LiteLagInfo` when the entry qualifies for heap insertion (`size < topK || diff > peek`), avoiding N-K wasted allocations. 3. **Replace `split()` with `indexOf()`**: Parse `topicAtGroup` key via `indexOf` + `substring`, avoiding array allocation; check lite prefix before any string extraction. 4. **Replace `AtomicLong` with `long[]`**: The traversal is single-threaded; atomic overhead is unnecessary. ### Describe Alternatives You've Considered - Caching store timestamps in memory: adds complexity and staleness risk without proportional benefit. - Parallel timestamp lookup: over-engineering for a metric query that is already fast after deferral. ### Additional Context Files changed: `LiteConsumerLagCalculator.java`, `LiteLagInfo.java`. -- 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]
