Performance Tuning - Documentation topics on: cache,database,java,log4j,performance tuning,profiling,velocity page profiling,.

Performance Tuning

dotCMS makes every possible effort to deliver a well-tested, out of the box configuration that works in most situations without requiring any special configuration. However depending on the nature of your site, you may want to make specific configuration changes to improve site performance.

There are many factors to consider when performance tuning dotCMS, and as with most computer performance considerations it may require some trial and error. dotCMS runs on many different combinations of hardware and operating systems, and can be configured with a huge variety of open source and custom features and code. Each of these have specific options and performance considerations, and you will have to discover the best options to meet the business and performance needs of your site.

With that in mind, here are a number of areas of your dotCMS configuration that you can review to tune and improve dotCMS performance:

Performance Settings

Java Virtual Machine (JVM) Settings

Since dotCMS is a Java application, it's important to ensure your JVM settings are set properly to achieve optimal performance.

Tomcat Application Server

By default, dotCMS runs on the Tomcat application server shipped with the dotCMS distribution. The dotCMS Tomcat distribution configures the JVM based on the JAVA_OPTS environment variable, and you can modify the options in this variable to adjust the amount of memory used by your JVM and to configure features and options such as garbage collection.

The following shows the Java options set in the default dotCMS distribution (Linux version):

set JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true -Xverify:none -Dfile.encoding=UTF8 -server -XX:+DisableExplicitGC

rem Set Memory sizing
set JAVA_OPTS=%JAVA_OPTS% -XX:MaxMetaspaceSize=512m -Xmx1G

rem Set GC opts
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseG1GC

set JAVA_OPTS=%JAVA_OPTS% -Djava.endorsed.dirs=%DOTCMS_HOME%/WEB-INF/endorsed_libs

rem Set agent opts
set JAVA_OPTS=%JAVA_OPTS% -javaagent:%DOTCMS_HOME%/WEB-INF/lib/byte-buddy-agent-1.6.12.jar

However if there is a JAVA_OPTS environment variable set before dotCMS is run, dotCMS will take the value of that environment variable instead (and will not set any of the above options). Therefore, if you wish to change the Java options, you may do one of the following:

  • Set a JAVA_OPTS system environment variable before starting dotCMS.
  • Modify the Java options in the script used to start dotCMS (in the bin directory in the dotCMS distribution folder)
    • Linux: startup.sh
    • Windows:
      • When started as an application: startup.bat
      • When running as a service: wrapper.conf

Other Application Servers

To change the JVM settings on other application servers, you may use the same command line options when starting Java; however the names of files and environment variables will vary depending on the application server used and how it is configured. For more information, please see the documentation for your specific application server.

Memory Limits for Plugins and Custom Code

In the dotCMS distribution, the default setting for the Java MaxMetaSpaceSize property is 512 mb. This limit ensures that your dotCMS instance will not run out of memory by growing too large for your server memory. However if you have a significant amount of custom or plugin code, this may not provide enough space for your code to run without hitting memory limits within Java, and you may need to increase this limit.

Database Configuration

Database performance can have a significant impact on dotCMS performance, and it is very important that your database is configured for maximum performance, especially for large sites.

Follow this link to learn how to configure your database connections within dotCMS.

In addition, please see the following for resources on performance tuning your specific database:


Important

The H2 database supplied with dotCMS is intended for demonstration and evaluation purposes only. It is not intended for production sites, and should not be used when evaluating or optimizing performance.


Cache Configuration

One of the most important areas impacting performance of large sites in dotCMS is the cache. dotCMS Enterprise editions allow customization of cache providers and settings to optimize performance. Follow this link to learn how to configure the cache.

Specifically, there are a number of cache regions which need particular attention when tuning performance, especially for large sites and sites with high utilization of some specific features.

Cache Region |

FeatureCache Region(s)
(configuration file name)
Area of Performance Impact
Generalcontentletcache, identifiercache, versioncache, versioninfocache 
Filesfileassetmetadatacache 
Categoriescategorycache, categorychildrencache, categoryparentscacheBack-end (content editing), Category content pulls, Category ES/Lucene queries
Relationshipsrelationshipcachebyinode, relationshipcachebynameBack-end (content editing), Related content pulls

Logging Configuration

Log file messages can provide significant help when troubleshooting and debugging problems, but during normal operation excessive logging can significantly impact performance, especially on large systems. The following changes to logging configuration may help to improve performance.

Logging Slow Performers

In addition to these measures which can improve the performance of logging itself, you may also use certain logging features to help identify issues in other features which may be reducing performance. For more information on each of these logging features, please see the Special Logging Configurations documentation.

Permissions Configuration

When Permissions are changed on a high-level object in dotCMS (such as a Site or top-level folder), the Permissions must be updated also for all lower-level objects which inherit Permissions from the object which was changed. For performance reasons, dotCMS performs all Permissions changes to lower-level objects “lazily” by default, meaning that the lower-level object Permissions are updated only when the lower level object is accessed.

However in earlier versions of dotCMS, Permissions updates were performed “eagerly” (meaning all the Permissions changes on all lower level objects were performed immediately), and dotCMS contains a configuration parameter which can be set to revert to the former behavior (which can have a negative impact on performance).

To ensure that Permissions changes have a minimal impact on performance, verify that the PERMISSIONS_REFERENCES_INSERT_LAZILY property in the dotmarketing-config.properties file is set to false.

PERMISSIONS_REFERENCES_INSERT_LAZILY=false

Profiling

The Logging Slow Performers section (above), gives links to documentation sections describing how to identify slow Elasticsearch queries, Rules, and SQL queries. In addition, you may perform profiling on the following additional areas with potential for a performance impact in dotCMS:

Startup Time Profiling

Each time you start dotCMS, the amount of time taken by each phase of the startup process is measured and recorded. if the startup times for your dotCMS system are longer than expected, or appear to be increasing, you can use these values to help identify both which phases of the startup process take the most time, and if the length of any phases of the startup process are increasing over time.

To view the startup profiling information, select System -> Maintenance, and open the System Info tab. Below the Environment Variables section, the following values will be displayed in the list of dotCMS system variables:

PropertyDescription
dotcms.startup.msThe total dotCMS startup time.
dotcms.startup.cache.msThe total time required to initialize all cache regions.
dotcms.startup.db.msThe time required to start up and connect to your database.
dotcms.startup.es.msThe time required to start Elasticsearch and load all indexes.
dotcms.startup.quartz.msThe time required to start the quartz scheduler and scheduled jobs.
dotcms.startup.osgi.msThe total time required to start all OSGI dynamic plugins.

Notes:

  • All startup times are recorded in milliseconds.
  • The startup times are also saved to the system.properties file (dotserver/tomcat-X.x.x/webapps/ROOT/WEB-INF/classes/system.properties).
    • To track the startup measurements over time, you can review copies of the system.properties file in your backups, or save copies of the file periodically.

Execution Time Profiling

dotCMS ships with the open source Glowroot profiling library to enable easy execution profiling of both the dotCMS code and your plugin code. However for security and performance reasons this library is disabled by default. You may enable profiling with Glowroot by starting dotCMS with the profile option:

bin/startup.sh profile

For more information on using Glowroot, please visit the Glowroot web site.

Java Memory Profiling

You can use JConsole to profile the memory use of dotCMS. Simply uncomment the following line in the startup.sh/startup.bat file and restart.

JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=7788 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

Important: If you are having memory troubles and want to see what is happening in realtime this is an invaluable tool, however java profiling significantly reduces performance. Your site will suffer a performance hit as long as the profiler is enabled, so make sure to comment out the line again once you are done.

For more information on tuning Java performance, please see the Java Performance Tuning White Paper.

Velocity Page Profiling

Sometimes performance issues are limited to a subset of pages, and the biggest challenge is to find these pages. To find these problematic pages dotCMS provides a Velocity page profiler. To enable it, you need enable DEBUG logging on the com.dotmarketing.velocity.VelocityServlet$PageProfiler class. This can be done on the log4j2.xml file, by inserting a logger:

    <logger name="com.dotmarketing.velocity.VelocityServlet$PageProfiler">
        <level value="debug"/>
    </logger>

Alternately you can enable Velocity page profiling on a running server by using JMX. To do this, pass com.dotmarketing.velocity.VelocityServlet$PageProfiler as a parameter to the enableDebug operation of the org.dotcms.Log4J MBean.

When Velocity Page Profiling is enabled, messages similar to the following will be written to the log file, displaying the time taken for the Velocity code to run for each page:

[11/09/09 10:18:17:017 EDT] DEBUG velocity.VelocityServlet$PageProfiler: VelocityPage time: http://demo.dotcms.org/home/directory.dot 17 millis