Performance issues
Insufficient system resources for Deeplearning4j operations
If you experience memory or performance issues when using the Deeplearning4j library, consult first the recommendations in Deeplearning4j: Memory and check them against the configuration of your system. Pay special attention to Configuring Memory Limits and Gotchas: A few things to watch out for.
Slow Admincentral with many tasks and notifications
Admincentral might get slow over time. One of the possible causes – especially when there is 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=67108864
These options will increase the cache size to 256 MB. Be aware that memory is allocated from the Java heap.
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 info.magnolia.module.cache.filter.CacheFilter. Its 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 DevTools 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 environment issues rather than Magnolia. |
To improve performance, try these suggestions in the following order:
-
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.
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 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
Admincentral module.