Environment details
Number of groups | 15000 |
Number of users | 3000 |
Number of spaces | 5000 |
Times measured are TTFB (time to first byte) of rest callsrequests made by client browser.
Groups
...
Action | Time | Explanation |
|---|---|---|
1st access of |
...
group space |
...
14.55s |
Subsequent first access of spaces: 2.95s
Subsequent access of cached space: 136ms
Member listing
First access of members of group (3000 users): 1.2mins
CSUM gets all groups and calculates which "belong" to the current Space as per the "matching pattern". Once calculated, this information is cached for future use (expiring after 30 minutes of inactivity). | ||
2nd access of group space | 136ms | The calculated groups for the space are retrieved from CSUM's cache. |
Users
The "large group" referred to below is a user group consisting of 3000 members.
Action | Time | Explanation |
|---|---|---|
1st access of large group membership | 1.2mins | CSUM relies on Confluence's own user cache to retrieve users. If its own cache has not "warmed up" yet, CSUM has to wait for this to be done (once per Confluence startup). |
2nd access of large group membership | 3.15s | Confluence's user cache is now "warmed up". |
Large group processing
We find that groups with members over 5K tend to be slow to load (the larger they get the more likely the load would fail entirely). There is an alternate feature for managing large group members, which is recommended until a better paging system is implemented.