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.
Caching is crucial for website performance. Without caching, OpenCms may perform poorly since it has to perform lots of expensive database queries. To guarantee performance, OpenCms features several caching mechanisms:
- Flex cache
- Image cache
- Core cache
- JSP repository
- Static export
There follows a brief overview of all 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 a website. A good configuration of this cache can significantly minimize the workload of your server. On the other hand, a wrong configuration may yield to unwanted results and even break functionality of your website. Because the Flex cache is so important, there is a whole topic about it.
For large-scale website projects there is an additional commercial extension available called OCEE Accelerator.
Images that are uploaded to the VFS are stored there in the format in which they were uploaded. 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 caches apps.
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, for example, a deleted file that does not disappear in the Explorer.
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 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.