RockteMQ-AI commented on issue #2578: URL: https://github.com/apache/rocketmq-dashboard/issues/2578#issuecomment-5410797527
## Bot Evaluation **Classification:** Bug โ Performance / Scalability **Severity:** MEDIUM-HIGH **Status:** โ Confirmed ### Verification Code verified on `rocketmq-studio` branch. `ConsumerGroupController.listConsumerGroupsPage()` (line 52, `GET /api/groups/page`) delegates to `MetadataService.listConsumerGroupsPage()` (line 186), which: 1. Calls `listConsumerGroups(instanceId, clusterId, search)` โ loads **every** matching group from DB 2. For Apache instances, each group is enriched with live admin/API data (online status, lag, delay) 3. Builds the full VO list in memory 4. Finally slices one page via `groups.subList(from, to)` Each page request is therefore O(total groups) in both DB rows and live admin calls, completely defeating the purpose of pagination. ### Inconsistency Topics already have a proper DB-level `listTopicsPage` implementation with server-side pagination. Consumer groups should follow the same pattern. ### Suggested Fix Direction 1. Add a DB-level `listConsumerGroupsPage(instanceId, clusterId, search, page, pageSize)` with SQL `LIMIT/OFFSET` and a `COUNT(*)` query for total. 2. Only enrich the page-sized subset with live admin data (not all groups). 3. Return `PageResult` with `items`, `total`, `page`, `size`. 4. Apply the same pattern to any other `*Page` endpoints that currently load-then-slice. --- *Evaluated by github-manager bot ยท [issue-evaluator]* -- 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]
