Performance tuning tips for AEM 5.x

Merk:

You are reading the AEM 5.x version of performance tuning tips. This article is also available for the versions 6.x

Issue

My CQ5 instance performance is poor.

Cause

Performance problems in CQ5 can be due to many things in combination. The most common cause is due to application code. However, you can take some measures within the CQ5 configuration to improve performance.

Resolution

To improve the overall performance of the CQ instance, Adobe recommends that you do the following (on author and publish instances).

1. Install recommended hotfixes

This applies for AEM 5.6.1. Please read carefully https://helpx.adobe.com/experience-manager/kb/cq561-available-hotfixes.html and install the recommended hotfixes for your modules, especially the one related to performance.

2. Increase in bundleCacheSize CRX

Increase the bundleCacheSize param of CRX TarPersistenceManager by doing the following:

Edit each of the PersistenceManager elements in your repository.xml and all of your workspace.xml files by adding the following parameter within the <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager" /> element:
For example:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">

    <param name="bundleCacheSize" value="256" />

</PersistenceManager>

By default, this cache is set to 8 MB. Increase it to at least 256 MB, or even 512 MB, depending on how much memory you can assign to the JVM. If you have a JVM with the Xmx param set to 10 GB, then you set the bundleCacheSize to 1024 MB. If you're using a 32-bit JVM on Windows, your Xmx param is probably less than 1500 MB. Therefore, a reasonable value for the bundleCacheSize is 128 MB. Adobe recommends that you upgrade to a 64-bit JVM to allocate more memory to the JVM heap.

3. Use the FineGrainedISMLocking (CRX 1.4.x only)

To configure it, add following the following ISMLocking class to the workspace.xml and repository.xml, directly after the SearchIndex block:

<Workspace ...>

    ...

    </SearchIndex>

    <ISMLocking class="org.apache.jackrabbit.core.state.FineGrainedISMLocking"/>

    ...

</Workspace>

4. Disable the CQ5 AssetSynchronizationService (CQ5.3 only)

The AssetSynchronizationService synchronizes assets from mounted repositories (for example, LiveLink, Documentum). When enabled, it has been observed that this service periodically allocates many objects which get garbage collected. Therefore, it has an impact on the performance of the JVM. If you do not use mounted repositories, you can disable this service.

By configuration, the synchronization period can be set to a higher number of seconds (default 300), thus factually preventing it from running.

The attached package sets the sync period to one year, thus disables the service.

5. Set CRX Search Index's resultFetchSize param

If the result set of a jcr query is large, then the loading the complete set and checking ACLs on them is expensive. To remedy it, limit the fetch size to 50 as via the SearchIndex element in the workspace.xml:

<param name="resultFetchSize" value="50"/>

For example:

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">

    <param name="path" value="${wsp.home}/index"/>

    <param name="resultFetchSize" value="50"/>

</SearchIndex>

6. Set the CRX Search cacheSize param

The search cacheSize can also be set in the SearchIndex element in workspace.xml. Set this parameter to 100000:

<param name="cacheSize" value="100000" />

For example:

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">

    <param name="path" value="${wsp.home}/index"/>

    <param name="resultFetchSize" value="50"/>

    <param name="cacheSize" value="100000" />

</SearchIndex>

This parameter is documented here.

7. Disable CRX clustering (CRX 1.4, 2.0, 2.1)

When running a system with high write load (for example, with massive imports of DAM assets), sometimes even relatively small write performance gains can help achieve required performance benchmark. In such case, consider turning off clustering journal in your deployment.

By default, CRX is set up to run in cluster mode. But if there is only one instance in the cluster, then it adds some I/O overhead. To gain write performance, disable clustering.

In the repository.xml, comment out the <Cluster ...>...</Cluster> section.
Then use the sample script to move the repository files from cluster mode to single mode.

Before doing this procedure, contact your daycare or your account manager to discuss this option. Most of customer's deployments run with the default, journaled configurations. It is best to test this script on a test instance doing it on a production system.

8. Disable Content Finder Refresh and Auto Load (Author instance only)

See this article [2]

9. Disable DAM Sub Asset Generation

See this article [3]

10. Limit the Max Journal Size in CRX

If the CRX journal files under share/journal grow too large, then your application can experience some slowdown. See this article [4] for how to limit the journal size and maximum number of files.

11. Disable DAM workflows on publish (CQ5.3 Publish instance only)

See this article [5]

12. Disable the Link Checker

A gain in performance can be had by disabling the link checker (especially with AEM 5.6.1). Only do this if you decide that you do not need it in your environment.

The link checker validates that resources URLs on your pages address are reachable. It does this by doing an HTTP HEAD request.

If a link is marked invalid on author, then the link checker displays a broken chain icon around it. If a link is marked invalid on publish, then the surrounding <a href="..."> tag is removed.

Some clients disable it in their publish instances to gain performance. Although this gains performance, broken links affect your site's SEO. Consider the effects carefully before deciding to disable it.

For instructions on disabling this feature, see this article [6].

13. Cache Tar PM index

Until CRX 2.1

Using a cron job to read the index*.tar file from time to time, can help to improve the performance, as the tar index is cached in the hardware I/O cache. On UNIX, you can load the index*.tar using the "cat index*.tar > /dev/null" command. Doing that every hour should help to improve the performance of the Tar Persistence Manager while executing TarFile.readFully() method.

From CRX 2.2 + hotfixpack 2.2.0.26 and later

Check the global size of the index_*.tar files in the crx.default workspace, increase the max heap size by such size, and set the indexInMemory param to true for the TarPersistenceManager section of the workspace.xml :

The heap space required for one JCR node is 128 bytes. If the largest index*.tar file of a workspace is 1 GB, that means there are about 16 million nodes in this workspace, as each node needs 64 bytes of disk space. Using the in-memory index option requires about 2 GB of heap space (double the file size to calculate the heap space required because there can be two versions per index file during index merge).

14. LDAP cache expiration

To improve the performance and reduce latency during authentication process, it's good to increase the LDAP cache expiration, you can set cache.expiration to 86400 (one day) in your LDAP configuration.