Performance Optimization of an AEM instance is one topic which gets neglected during almost all the development phase and when the site degrades in various levels , a concern is raised for checking the Performance of the system. Lately I have been working on a lot of projects wherein there was this problem and we were able to sort out the issues by following a well-defined structured approach . By this blog post , I would like to point out several areas which might be responsible for the system degradation. Also after explaining the issues , I would point respective recommendations which you may follow to improve the performance of AEM instance.
FREQUENTLY USED TOOLS
|Tool||Used For / Description||How to Use ?|
|request.log||This is very vital tool if you want to analyze the request time for various requests. It would help you know which request is taking max time and how often the request is occurring with max time.||Use this Link|
|DU Reports||Disk Usage Reports is used when you need to find which folder is taking the maximum space.||/etc/reports/diskusage.html|
|JMeter||This is basically used widely for Load Testing and Functional testing of the application.||http://jmeter.apache.org/|
|JConsole||It is used to Observe JVM metrics and threads||Use the link|
|JVisualVM||It is used to Observe JVM metrics, threads, memory and profiling||Use the link|
|YourKit Profiler||This is a very powerful Profiler which could be used for either Remote or Local environment .It is mainly used for CPU and Memory profiling.||https://www.yourkit.com/|
|CQ In Built Profiler||This is OOTB provided by CQ, but it has very minimal application .||/system/console/profiler|
- Infrastructure Sizing : This could be the first point of check which should be performed. The Hardware sizing for an application depends on various factors and in most of the cases due to improper hardware , the AEM instance doesn’t perform as per expections . The LINK gives a detailed bureau of what should be hardware guidelines based on your system. Proper calculations should be performed to check whether the chosen hardware is apt or not.
- Unusual Rapid Repository Growth : If your AEM instance (Author or Publish) is facing an unusual repository growth, it could be a major reason for degraded performance. There could be several reasons for this :
TAR PM Optimization Not Functioning : Sometimes it happens that the TAR PM optimization isn’t able to perform the task of reducing the TAR nodes size due to vast number of nodes or maybe due to shortage of allocated time-span . If this continues for sometime, there would be ever-increasing repository size. In order to rectify this issue , the first step could be to check what is causing such a huge number of TAR files. LINK. Secondly you could increase the allocated time-span for TAR Optimization. Also you may consider to Manually initialize the TAR PM Optimization and run it completely. Manual intiation could be done either using JMX console or placing a file optimize.tar in the folder where tar files are present. Read More
Link Checker : There could be a scenario where Link Checker is constantly running on various external links , creating JCR locks which might lead to decrease the performance. If you will analyze the TAR files as stated above, you will find the number of Link Checker nodes or else you can also initiate a TRACE log for org.apache.jackrabbit.oak.jcr.operations.writes for a few minutes only. If the performance is compromised , its advisable to disable Link-Checker. AEM6 AEM5.6
Workflows / Audit Nodes : If the application is using a lot of Workflows , it is advisable to schedule a proper Workflow Purge. This could be done either using a Scheduler or by using a Watch folder . Similarly audit nodes could be purged using Watch folder approach.
Version Nodes : Version purging could be initiated using a console /etc/versioning/purge.html .
It is advisable to first perform all the purging activities and then go for TAR PM Optimization for better results.
- Lucene Indexing Optimization : Many a times it happens that an AEM instance keep on performing Lucene Indexing at frequent intervals .It occurs mostly when there are a lot of User Generated Content (UGC) or very frequent changes in the content . Also the OOTB Lucene indexer indexes every OOTB node and property present in an instance . This eventually gives a performance hit to the system as the process occupies a lot of CPU usage. In order to Optimize the Lucene Indexing , we should index only those nodes / properties which are used in our Search Algorithms and skip for other nodes. This can be achieved by introducing an indexing-config.xml file as stated in the Adobe documentation.
As different applications have different concerns , it might be possible that not all the reasons mentioned above would be the root cause of the problem. But the list here will definitely give you the pointers to look for in your system.
- Hotfixes : The first task to improve performance of the system is to make sure that the Hotfixes are in place for that version of AEM. LINK
- Performance Tuning Tips : There are various Performance Tuning Tips which Adobe recommends which might be useful and quite handy. AEM 5.X AEM 6.0
APPLICATION LEVEL PERFORMANCE ISSUES
In order to monitor application level Performance issues, there are a few things which could be done to monitor and improve the application :
- GTMETRIX : Currently this is the best free tool available in the market to analyze a webpage for various issues. It covers a wide variety of problem areas like CDN issues, clientlibs JS issues, image size and other necessary web application standards . I strongly advise to make use of this tool.
- Timing Component : AEM comes with an OOTB timing component . You may include this component on the page and then it will display in a graphical chart format the timing analysis of various JSPs on a page. This could be your starting point to work . Read more
- Make sure there are no Errors present on a page. You may check either the error logs or the Touch UI developer console.