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.

Find Bar querying slows down the instance

When Admincentral initializes, the Find Bar is querying the full user repository including the public users. This may lead to a massive 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 Administration module page.


Memory sizing issues

Magnolia's Find Bar uses AI that is based on Deep Learning for Java (Deeplearning4j) to present the user with the most relevant results. Magnolia creates one neural network per Magnolia user. Behind the scenes, that library maps each user to a chunk of off-heap memory.

The problem that some instances run into is that DL4J's default behavior is to allow as much off-heap memory available as Xmx. Meaning that on a server where 4G of RAM are reserved for Magnolia, the whole process might consume up to 8G RAM, which will lead to memory starvation on a 8GB or less system, for instance.

While that default makes sense for AI projects, AI in Magnolia is a small fraction of what the Java process does. This default should therefore be overriden. To achieve this, the following flag can be used: -Dorg.bytedeco.javacpp.maxbytes

For instance:

  • Xmx is 4G
  • -Dorg.bytedeco.javacpp.maxbytes=400M
  • Magnolia will require 4.4G of physical RAM in total

Since the 6.2.2 release, which bundles DL4J 1.0.0-beta7, and its dependency javacpp at version 1.5.3, we recommend to use relative units instead:

  • Xmx is 4G
  • -Dorg.bytedeco.javacpp.maxbytes=10%
  • Magnolia will require 4.4G of physical RAM in total, and will adapt regardless of the environment it is run on

Insufficient system resources for Deeplearning4j operations

  1. If you experience memory or performance issues when using the Deeplearning4j library, please consult first the recommendations given on and check them against the configuration of your system. Pay a special attention to the advice mentioned in the following two sections on the page:
    1. Configuring Memory Limits
    2. Gotchas: A few things to watch out for

  • No labels