Caching in Vertical Site

14/10/2008 10:46 by Sten Roger Sandvik

In this article I will describe the basics on how the caching works in Vertical Site. The caching system was changed a great deal in version 4.2 so I will only focus on the newest versions of the product.

We have a central caching mechanism in Vertical Site that manages all the caching aspects, from frontend page caching to backend database caching. All the caches is global and is therefore shared between all sites on an instance. This means that you have more control over the configuration and memory footprint of the cache.

In the sections below I will try to describe the various types of caching, how to look at the cache details, configuring the caches and last how clustering works on top of the caches.

Cache types

In Vertical Site we have various cache types. It is important to know all the cache types so you can be able to tune the caches individually. In certain cases you also need to manually clear the cache. The various cache types are outlined below:

• Page Cache (page). This is used to cache all pages and objects for all sites. Vertical Site clears individual pages (and objects) based on a timeout value (or time-to-live).
• Binary Cache (binary). All binaries are cached in this cache. It is very important to limit this cache since it can use alot of memory. Items inside this cache is evicted based on a timeout value.
• Precompiled Xslt Cache (xslt). All xsl stylesheets that is used in Vertical Site is compiled and placed inside the xslt cache. Items here are evicted based on xslt stylesheet changes and evicted automatically.
• Entity Cache (entity). This cache is used for Hibernate entities (or database objects). It is used for menu items, page configuration, resources and all other low-level database objects.The items inside the cache is automaticall evicted based on changes to the model.
• Compability Cache (item). All other values that might be using a cache that is not specified above will use the item cache. It is only temprary and will be removed in later versions of Vertical Site. No need to evict this manually since it is managed by the internal state.

So, then we know the various types. The next section describes how to look at the cache statistics and manually clearing the cache.

Cache details

All cache details can be listed in the administration console. Before Vertical Site 4.3.2 you must go under each site to view the cache details. But in 4.3.2 and after we have placed the cache details in Admin tab under Admin menu item.

When we look at the cache details, we do not necessary see all the cache types. If we do not see the entry for a specific cache type it does not have any items. The statistics shown under each cache type is described below:

• Time to live. This is the time (in seconds) an item inside the cache will live before beeing evicted. If this value is 0 (zero) it will live forever.
• Max elements in memory. Number of elements that can live inside the cache. This value is very important to tune, but a larger value requires more memory.
• Object count. This is the number of items that actually resides inside the cache. If this value is equal to max elements in memory the oldest (or most unused) item will be evicted from the cache.
• Cache hits. Number of hits (or successfull read) from the cache. If the item can be found in the cache it is registered as a hit.
• Cache misses. Number of misses (or unsuccessfull read) from the cache. If the item cannot be found in the cache it is registered as a miss.

So, the details above is used to be able to tune the cache. It is very important to set the max elements in memory to a good value. Ideally every item shoud be cached, but sometimes it is not feasable. To monitor the successrate of the cache, we can look at number of hits versus misses. Hits should be increasing more rapidly than misses. All statistics can be cleared safely at any time.

Sometimes it is necessary to manually clear the cache. This can be done by clicking the clear cache button. When this button is hit, every item in the cache type is cleared across all sites.

Configuration

Caching can be configured in the cms.properties file under $CHSM_HOME/config. Every changes here requires a full restart so it is important to know what you are doing here. An example confiuration is shown below:

cms.cache.entity.memoryCapacity = 100000
cms.cache.entity.timeToLive = 0
cms.cache.binary.memoryCapacity = 1000
cms.cache.binary.timeToLive = 3600
cms.cache.page.memoryCapacity = 5000
cms.cache.page.timeToLive = 600

As seen, this follows a pattern. Every cache can be configured by using the property values cms.cache.type.memoryCapacity and cms.cache.type.timeToLive. MemoryCapacity is the upper bound of items that can exists in a cache and timeToLive is the number of seconds an item can exist in a cache (0 means live forever).

On each site we can override the timeToLive property for each cache and also enable or disable caches. Site specific configuration is set in the site-x.properties file (where x is the site key). An example of some cache settings in site-x.properties:

cms.site.pageCache = true
cms.site.binaryCache = false
cms.site.cache.page.timeToLive = 600
cms.site.cache.binary.timeToLive = 3600

Clustering

Vertical Site has transparent clustering over all the caches. This means that if clustering is enabled all cache operations are reflected over all cluster members. The clustering is disabled by default and needs to be enabled to have this feature. I will not go into depth on how the clustering works here, but will show how to enable the cache and do some simple configuration of it.

To enable the clustering we need to set a property into the cms.properties file. This requires a restart for Vertical Site to see the changes.

cms.cluster.enabled = true

If we do not setup anything else it will use default confgiuration of the cluster. But this can be changes with the following values.

cms.cluster.name = mycluster
cms.cluster.multicastAddress = 231.12.21.132

The cluster name needs to be unique in each cluster group. If you have many cluster groups you will need to change the cms.cluster.name value to something unique per group. The multicast address does not need to be changed unless you experience problems with the package routing. So leave that alone if you do not know what a multicast address is.

To test the clustering you can use the cluster test interface on Vertical Site welcome screen. The page shows cluster information and can be used to manually test the sending and recieving of cluster events. This page is usually on the url http://host:port/tools/cluster.