There are some basic initial configurations we can set to get a better performance out of our CQ instances. An average performance target value can be defined. Once this value is proven to be both achievable and maintainable, it can be used to monitor the performance of the website and indicate the development of potential problems.
- Optimize Tar Files: As data is never overwritten in a tar file, the disk usage increases even when only updating existing data. When optimizing, the TarPM copies data that is still used from old tar files into new tar files and deletes the old tar files that contain only old or redundant data. If there is only one file, optimization will have no effect. By default optimization is automatically run each night between 2 am and 5 am. and alternatively you can start optimizing the tar file manually.
- Merge Tar Index Files: If many entries are stored in the tar files, the number of index files may grow. The index files are automatically merged before and after the scheduled Tar PM optimization. To reduce the number of index files at other times, you can merge these index files manually through the JMX console.
- Consistency Checks: The Tar PM can check repository consistency and fix consistency problems at startup.
- Run Garbage Collector for Data Store: When a conventional WCM asset is removed, the reference to the underlying datastore record may be removed from the node hierarchy, but the datastore record itself remains.
- Check DataStore Consistency: CRX can check the consistency of the datastore to confirm that objects expected to be available in the datastore are actually there. Any datastore inconsistencies found will be logged.
- CRX search index’s resultFetchSize param: The SearchIndex element specifies the configuration of the search engine. By default the search index is managed by the text search engine Apache Lucene.
- TarJournal File Maximum size: Maximum size of a single journal file before it will get rotated. Default: 104857600 bytes (100 MB).
- Set logging level: By default logging level is set to INFORMATION. For performance purposes it can be switch to ERROR and set back to INFORMATION or DEBUG as required (logging levels: trace -> debug -> info -> warn -> error).
- Apache Sling JSP Script Handler: To improve performance you should disable as much as possible. In particular for production instances: disable Generate Debug Info, disable Keep Generated Java, disable Mapped Content, disable Display Source Fragments.
- Apache Sling Java Script Handler: Configure settings for the compilation of .java files as scripts (servlets). for production instances: Source VM and Target VM, define the JDK version as that used as the runtime JVM, disable Generate Debug Info.
This is the last part of our series of blogs discussion “Gold-Copy”. Remember to keep track to all configurations so you know what has been set, when it was set and who is accountable for it.
Every new developer should be given a copy of “Gold-Copy” and a set of instructions on how to install other tools such as JDK, Eclipse, Maven and Vault. Whenever you set new configurations you should share across all team members via CRX Packages. Should you restore a running production instance you can deploy your gold-copy and install CRX Packages for code and content.
I’m a relative CQ newbie. I went through Adobe training and have been working with the program for the last couple months. I’ve been using it long enough to have had my own fair share of tragedies. Thanks for the post. Good tips.