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 Engine 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
Escenic
configuration files, see
Configuration File Format. You can also
make temporary changes to cache settings while the
Content Engine
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 Engine'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'
PresentationArticleCache
s, 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 Engine 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.