Performance issues

AdminCentral UI is slow

AdminCentral UI might get slower over time. One of the possible causes – especially when there's no log indication of any specific issue – is a high number of messages and/or tasks stored in the user's profile. This number is indicated in the corner of the Pulse icon and can go as high as 99. Please be aware, though, that more than 99 messages and/or tasks can be stored in the profile, i.e more than what is actually indicated at the Pulse icon:

You can check the total number of messages stored in your profile in the Pulse. The total count should be displayed in the right bottom corner:

If the number exceeds several hundreds, try removing all the non-essential messages. Please note that you should not experience a UI performance degradation unless more than several thousands of messages are stored in your profile.

To delete messages or tasks, check the "New" checkbox located above the first message:

By checking the box, you have selected all messages. At the bottom of the UI you will see "With checked do". Click the arrow and select "Delete":

Messages and tasks are aggregated by Group. If a person belonging to the Editors group deletes all messages, this action will impact all others in that Group. Finally, remember to check all Author instances for a high messages and tasks count - Production, UAT/QA, Dev and others. 

URL took longer than n seconds to render

Magnolia logs warning messages when URLs load slowly:

This message is not produced by Ehcache, but by Magnolia's CacheFilter. It's purpose is to let you know that your installation is not behaving optimally. Enable debugging on cache related classes to find out whether resources are served slowly from the cache or the repository. You can also use Firebug or Chrome's developer tools to see how long it takes for a resource to be received by the server. This may provide hints to narrow down the issue. For example, images stored at a CDN may be served slowly.

 This type of issue arises mostly due to environmental issues, rather than Magnolia directly.

To improve performance, try these suggestions in the following order:

• Check the memory and CPU usage. If the capacity assigned to 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 PerformanceTestFilter to find out how long a subchain of filters takes to execute. Add the PerformanceTestFilter in different positions in the filter chain in /server/filters. Identify which filters take a long time to run.