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:
-Dorg.apache.jackrabbit.maxCacheMemory=268435456
-Dorg.apache.jackrabbit.minMemoryPerCache=1048576
-Dorg.apache.jackrabbit.maxMemoryPerCache=67108864These options will increase the cache size to 256 MB. Be aware that 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.
-
Check the memory and CPU usage. If the capacity assigned to the server is used up, assign more resources.
-
Establish when the issue occurs. All the time? At certain hours? Can you match it to publishing or running bulk load operations like huge import handler jobs? Does it coincide with a spike in visitors? Are both instances affected?
-
Identify the filters that cause the issue. You can use info.magnolia.debug.PerformanceTestFilter to find out how long a subchain of filters takes to execute. Add
PerformanceTestFilterin different positions in the filter chain in/server/filters. Identify which filters take a long time to run.
Slow browser subapp due to multiple operations triggering workspace observation
When many users create many items in the workspace concurrently, too many automatic observation events in a short period of time could make a browser subapp with grid nearly unusable. Configuring the observation mechanism is possible by changing delays for processing events or even disabling the automatic observation completely.
Turning the automatic observation property off would mean no automatic browser subapp refreshing, but only when a user performs some action. Reducing the number of observation events reduces the number of updates to the grid, making it more reactive. At the same time, the grid will be less up-to-date with changes made by other users.
See JCR observation definition for more information.