Performance issues
Slow AdminCentral with many tasks and notifications
AdminCentral might get slow over time. One of the possible causes – especially when there’s no log indication of any specific issue – is a high number of tasks and notifications stored in the user profile.
You can check the total number of tasks and notifications using the Tasks and Notifications apps, respectively.
| You should not experience performance issues unless more than several thousand items are stored in your profile. |
Tasks and notifications are aggregated by group.
If a person belonging to the editors group deletes all items, this action will impact all others in that group.
Finally, remember to check all author instances for a high number of items (production, UAT/QA, development and others).
| If multiple users are experiencing performance issues, each should check the number of tasks and notifications and resolve or delete all non-essential items. |
Slow AdminCentral with multiple editors
Concurrent access to the JCR might require a bigger Jackrabbit cache size. To adjust the default 16 MB, add the following parameters to your JVM configuration. They will increase the cache size to 256 MB:
-Dorg.apache.jackrabbit.maxCacheMemory=268435456
-Dorg.apache.jackrabbit.minMemoryPerCache=1048576
-Dorg.apache.jackrabbit.maxMemoryPerCache=67108864| Memory is allocated from the Java heap. |
Find Bar filtering slows down instances with a large number of registered users
When the filter icon is clicked in the Find Bar, the Find Bar queries the repository for all users including public users. This may lead to a performance degradation for clients with a huge number of (public) users.
You can configure the editorRoles property to limit the range of user roles allowed in the Last editor Find Bar search filter.
For more details, see the Admincentral module.