Listing of sessions is very slow when we have tens of thousands sessions (+ not able to know the exact number of sessions)

[omasseau]

Before reporting an issue

• I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

admin/ui

Describe the bug

When we have tens of thousands of active sessions for a realm. Displaying the sessions is very very slow.

Currently we have about 30k sessions. Going in th Sessions tab of the realm, it takes 40 seconds (spinner displayed) before showing the first 10 sessions.

Note that it would be nice if the UI could display the number of sessions. Currently it is impossible to know it (without manually querying the DB).

Version

24.0.3

Regression

• The issue is a regression

Expected behavior

Sessions screen should load faster when having many sessions

Actual behavior

Sessions screen is too slow

How to Reproduce?

Call the token endpoint to generate new tokens in a a loop in order to simulate many sessions

Anything else?

No response

[sschu]

@ahus1 is this a duplicate of #29203?

[ahus1]

@sschu - I don't think so, as the PR for the other issue didn't solve the general approach of fetching those sessions which is very inefficient.

@omasseau - can you elaborate if you are using online sessions or offline sessions? And if all sessions belong to a single client or to multiple clients?

[sschu]

@ahus1 I thought #29203 added pagination at least for stuff that is in memory but on a second look result.distinct().skip(first).limit(max); still goes over the whole stream because of the distinct().

[ahus1]

I am not sure about the distinct(), in theory you could have a distinct() which works incrementally, while sort() can't.

I see that InfinispanUserSessionProvider has a sort() which might sort 30k entries. This might be the root cause, but difficult to fix as we need some deterministic order for pagination. Once durable sessions are in, it should work better, also I see that I need to remove the sorting there as well.

[keycloak-github-bot]

Due to the amount of issues reported by the community we are not able to prioritise resolving this issue at the moment.

If you are affected by this issue, upvote it by adding a 👍 to the description. We would also welcome a contribution to fix the issue.

[martin-kanis]

Thank you for reporting this issue. The issue is there for quite some time and as Alexander mentions it should be improved by durable sessions feature that crossdc team is working on. Therefore we don't assign a high priority to this issue at this moment.

[ahus1]

I've tested with the latest version of the persistent sessions feature available as part of #28265 in the upcoming KC25 release.

I created 35000 sessions across 10000 different clients, and the list of sessions for a realm in the UI updated within less than 3 seconds for the first 10 pages. The more you paginate, the slower it will be.

To get the total number of sessions, this can be retrieved via the CLI as follows and it will get the number of sessions per client:

kcadm.sh get realm/realm-0/client-session-stats

In the example I used, this too about 30 seconds, mostly due to the number of clients involved as Keycloak validates each one of them and they didn't fit all into memory for me. For a smaller number of clients or an enlarged cache this shouldn't be an issue.

I tried the same with only 10 clients and 10 users, and again 30000 sessions, and there the responses where a lot faster (less than a second when listing the first page of users, and less than two seconds when using the admin CLI to retrieve the number of sessions)

With the main performance issue resolved, I consider this resolved.

If you want to show the number of sessions in the UI, please create an enhancement issue as this is not a bug.
Still beware, as showing the number of sessions can be quite quite slow, and we might need to use some performance optimizations here so it might include recently expired sessions as an approximation.
When opening the enhancement issue, it might be good to know more about the context where and how you want to use this number so we would know how to optimize it, or if we can show alternatives.