Page tree
Skip to end of metadata
Go to start of metadata

AdminCentral UI is slow

The 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 tasks and/or notifications stored in the user's profile. You can check the total number of tasks and notifications stored in your profile using the the Tasks and Notifications apps, respectively.

If the number exceeds several hundreds, try resolving or removing all the non-essential items. (warning) You should not experience a UI performance degradation unless more than several thousands of items are stored in your profile.

Tasks and notifications are aggregated by Group. If a person belonging to the Editors group deletes all notifications, this action will impact all others in that Group.

Finally, remember to check all Author instances for a high tasks and notifications count - Production, UAT/QA, Dev and others. 

Following this procedure will fix the UI performance only for your account. If multiple users are experiencing slower UI, each should check the number of notifications and reduce it if needed.

URL took longer than n seconds to render

Magnolia logs warning messages when URLs load slowly:

WARN info.magnolia.module.cache.filter.CacheFilter : The following URL took longer than 10 seconds (57369 ms) to render ...

This message is produced 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.

(warning) 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.
  • No labels