Search the documentation
 Show GitHub edit links  Hide GitHub edit links
Documented since: 9.5 Latest revision for: 9.5.2 Valid for OpenCms: 10.5.3

Caching is very important to obtain a well-performing website. Without caching, OpenCms will perform very poorly since it has to perform lots of expensive database queries. To increase performance, OpenCms features several caching mechanisms. These are in particular:

  • flex cache
  • image cache
  • core cache
  • JSP repository
  • Static export

There follows a brief overview all of these caches. Besides the flex cache, all of them work automatically and you may just have to clear them in some situations. In contrast, the flex cache is highly configurable and its configuration has a massive influence on the performance of your web site. You need to configure this cache for a performant website that also minimizes the workload of your server, but wrong configuration may yield unwanted results and even break functionality of your website. Because the flex cache is so important, we devtore a whole topic to it.

If all the caching mechanisms provided by the OpenCms core are not sufficient, you can purchase the non-free OCEE Accelerator.

The flex cache

The flex cache caches HTML output produced by JSPs. The HTML snippets are kept in the memory of the server. The snippets produced by a JSP may differ depending on various factors, e.g., the page on which the HTML snippet should be included, the user that is logged in, the current time, etc. To avoid using the "wrong" snippet of HTML, the flex cache is highly configurable and can cache various versions of the HTML output of a single JSP.

The image cache

Images that are uploaded to the VFS are stored there in the format in which they were uploaded if not larger than a globally configurable size. When an image is first requested, the image is scaled as requested (see the topic on image scaling) and the scaled version is exported to the RFS of your server. Exported image versions are found in the folder {webapp-home}/WEB-INF/imagecache/{VFS root path of the image}/. The name of the image is extended by a unique identifier for the version of the image in the RFS.

If the same image is requested a second time in the same version, i.e., scaled with the same parameters, the cached version is delivered. Neither the database request for the uploaded image nor the scaling procedure is repeated.

If the image is requested with different scaling parameters, the original version of the image is loaded again from the VFS, is scaled, and then cached as a second version of the same image.

You can view the state of the image cache and flush the cache via the cache administration.

The core cache

The core cache caches data used internally by OpenCms in the server's memory. It is a conglomeration of various internal caching mechanisms. For example, it caches user specific data or resource specific data like properties.

The cache can be configured via the opencms-system.xml, but usually the default configuration is sufficient. The core cache can be flushed via the cache administration. That may be necessary in some situations. Think of it if you experience unintended behavior when working with OpenCms.

The JSP repository

JSPs are the files that render HTML output. Rendering is not performed by OpenCms. It is done by the servlet container, e.g., by Tomcat. The servlet container needs to have the JSPs physically present in the RFS to render them. Hence, JSPs are first exported to the RFS before they are rendered. The JSP repository is placed in the folder {webapp home}/WEB-INF/jsp/. The subfolder offline/ contains the JSPs from the offline version of the VFS, the subfolder online/ the JSPs from the online version. The remaining sub-folders resemble the VFS folder structure. JSPs are usually exported when they are rendered the first time. If a JSP changes, it is exported again if it needs to be rendered.

Since export happens automatically when it is necessary, you usually do not have to touch the JSP repository. There is just one situation, where changes in a JSP will not propagate to the repository:

When a JSP that is included into another JSP via a hard include, i.e., by <%@include %>, and you alter the included JSP, OpenCms will not recognize that the whole outer JSP has to be updated. Then it's time to clear the JSP repository (or simply delete the affected JSP in the repository).

You can flush the JSP repository via the cache administration.

The static export

The static export allows to export resources from the VFS to the RFS. The feature applies only to the online version of the VFS. In particular, besides writing static resources to the RFS, static export allows to store already rendered web pages on the RFS. The rendering results are only updated when needed (either directly after a publish task has completed, or when a resource is requested for the first time after a publish task).

You can configure which resources should be exported, when export should happen and where the files on the RFS should be stored.

Read more about static export here.

You can improve this page

Please contribute your suggestions or comments regarding this topic on our wiki. For support questions, please use the OpenCms mailing list or go for professional support.