Tuning The Object Caches

You can tune the object caches by setting the following cache properties:

maxSize: The maximum number of objects allowed in the cache.
validSeconds: You can use this property to set a time threshold (in seconds) after which objects are removed from the cache. This prevents modified objects from surviving in the cache too long. However, the Content Store is in general efficient at removing invalid objects, so it can usually be set to -1 (which disables this process).

These properties are set by editing configuration files. For general information about editing CUE configuration files, see Configuration File Format. You can also make temporary changes to cache settings while the Content Store is running using the escenic-admin application's component browser (see Component Browser).

Ideally, all caches should be large enough to hold all the elements ever added to it: this would mean an element would never need to be loaded from the database more than once. In practice, this is unlikely to be possible due to memory limitations, so trade-offs must be made. Tuning the object caches is therefore usually a trial-and-error process aimed at finding the best possible set of trade-offs for a particular installation. If cache limits are set too low, the database will be accessed too often, resulting in reduced performance. If cache limits are set too high, memory can be overloaded, which also results in reduced performance. It is worth noting, however, that a high cache limit can only cause problems if the cache space is actually used: setting a cache limit too low, however, is guaranteed to have some effect on performance.

In general, the best way to tune the caches is to regularly check the performance summary displayed on the escenic-admin application's Performance Summary page (see Performance Summary). This summary contains a general Caches section for the Content Store's caches, plus individual sections listing information about the caches in each web application. For information on how to interpret the statistics displayed in these tables, see Cache Summaries.

When determining cache sizes you also need to take into account how much memory they will occupy, and this is a function of both the number of objects in the cache and the size of those objects. This is particularly significant in the case of web applications' PresentationArticleCaches, since the size of the objects held in them can vary widely. If a publication's typical content items are large, then its PresentationArticleCache may become very large. If you know the average size of the articles in a publication, then you can estimate the memory the cache is likely to consume as follows:

If an 'average' document is 15KB of plain (8-bit) text (either HTML or XML), it will basically occupy 30KB as a Java object because Java uses 16-bit encoding internally. In addition, there is a fixed overhead of around 5KB per article, giving a total memory requirement of around 35KB. So if you set the PresentationArticleCache's maxSize property to 10000 documents, the cache may require up to 350 MB of memory.

The following sections contain some basic items of useful information about each of the object caches listed on the escenic-admin Performance Summary page. The following information is provided about each cache:

The cache component name. This is the name you use to locate the cache in the component browser (although the easiest way to find it is just to click the cache's link on the escenic-admin Performance Summary page).
The cache configuration file name. This is the file you need to create or edit to make permanent changes to the cache configuration. Global Content Store cache configuration files may be added to one or more of your configuration layers. For information about configuration layers, see Managing The Configuration Layers. Web application cache configuration files must be added to the web application's WEB-INF/localconfig folder.
Typical object size. You need this to work out how much memory the cache will use when it is full.