Repository navigation
Performance: Loading all groups makes AdminUI unusable #1232
Description
Initial Checklist
- I understand this is a bug report and questions should be posted in the Community Discussions
- I searched issues and couldn’t find anything (or linked relevant results below)
Bug Description
Description
The opencloud User and group management UI displays a lot of information. To gather that, we are doing very expensive queries to the backend, which makes the UI completely unusable.
Root causes
https://cloud.keycloak-daily.opencloud.rocks/graph/v1.0/groups?%24orderby=displayName&%24expand=memberswhen opening the User Management.- Same expensive request to
https://cloud.keycloak-daily.opencloud.rocks/graph/v1.0/groups?%24orderby=displayName&%24expand=memberswhen opening the Group Management
These queries should be avoided. Fetching the groups is not problematic (1 sec or less) , but the expand=members kills it. That is only used to add a number to the groups in the list which does not add a lot of value because the assignments of a user can not be seen. We should avoid that in total.
The next problematic issue is the filter dropdown. The UX with more that 10 or 15 groups is not good. Imagine to have several thousand groups. Other UIs like the Keycloak UI use an autocomplete filter query field which scales better.
Reproduction Steps
- Create 50.000 users and 10.000 groups
- Browse to the Admin UI to "Users" or "Group" management
- White Screen, the Client does not respond within seconds.
Expected Outcome
The UI should be usable.
Actual Outcome
UI is not usable.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
tbsbdr commentedon Sep 22, 2025
How is it solved by others?
I'm not saying that this is the only way to go, just take it for inspiration:
Groups
Users
micbar commentedon Sep 22, 2025
Pagination is also a good idea, but requires more effort.
I was just suggesting a pragmatic fix: "Do not display things we can afford to drop for the sake of enabling opencloud for large istallations"
JammingBen commentedon Jul 17, 2026
In the users list, I think we're fetching the groups only for the filter and for the "Add To/Remove from Groups"-action. So I guess we could stop fetching them initially and only do it when opening the filter or a filter is applied (which can also be the case initially because of the URL query params), or when using one of these actions.
In the groups list, we would either need to kill the "Members" column, or the server can give the client a member count property via API.
JammingBen commentedon Jul 27, 2026
@micbar Are you 100% sure the request to
/graph/v1.0/groups(+expand) is what's taking so long?I did some tests with ~6000 users and groups. The request itself is still fast (milliseconds), and it shouldn't be blocking the UI. However, there is an issue in the UI table rendering process, causing all items to render initially, before rendering the paginated amount. I expect this to be the real issue for the slow loading and especially the unresponsiveness of the browser.
JammingBen commentedon Jul 29, 2026
Fixed by #2958 and #2963