Caching is very important to obtain a well-performing website. Without caching, OpenCms will perform very poor 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
We briefly 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 massive influence on the performance of your web site. You need to configure this cache for a performant website that also minimizes the work load of your server, but wrong configurations may yield to unwanted results and even break functionality of your website. Because the flex cache is such important, we spend a whole topic on it.
If all the caching mechanisms provided by the OpenCms core are not sufficient, you can purchase the non-free OCEE Accelerator.
1 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.
2 The image cache
Images that are loaded up to the VFS are stored their in the format they were loaded upif 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.
3 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 not the intended behavior when working with OpenCms.
4 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 changed, it is exported again when it should be rendered afterward.
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:
You can flush the JSP repository via the cache administration.