69
WEBSPHERE PORTAL V6.1 TUNING GUIDE
achieve best performance, in terms of cache hit rate, the size should be set to a value so
that all pages defined in the system fit into the cache. This corresponds to the row count
of the database table PAGE_INST.
com.ibm.wps.datastore.pageinstance.DerivationCache
Default size: 3000, default lifetime: infinite, usage pattern: regular.
This cache stores the mappings between pages and their derivation children, or empty
mappings if no such children exist. Like the pageinstance.OIDCache cache this one also
is accessed very frequently during page rendering and administration. Creating a cache
entry involves one multi-row database query. This cache also scales with the number of
pages in the system. Hence, you can use the same sizes for the previous cache and this
one. In most portal usage scenarios the actual size of this cache will be somewhat lower
than with the page instance cache. An average entry in the cache is rather small. Only if
all your pages have long lists of derivation children will the entries become larger. To
achieve best performance, in terms of cache hit rate, the size should be set to a value so
that all pages defined in the system fit into the cache. This corresponds to the row count
of the database table PAGE_INST.
com.ibm.wps.datastore.pageinstance.DynamicNodeCache
Default size: 5, default lifetime: infinite, usage pattern: regular.
This cache stores one list per domain. These lists contain all pages in the corresponding
domain that are flagged as dynamic nodes, i.e. dynamic assembly content nodes can be
added below these pages. Since the number of domains does not grow, the size as well
as other properties of this cache should not be modified. The size of one entry into the
cache ranges from small in a portal with very few dynamic nodes up to medium with
many dynamic nodes in the system.
com.ibm.wps.datastore.services.Identification.SerializedOidString.cache
Default size: 2500, default lifetime: infinite, usage pattern: cascading object types.
This cache stores serialized ObjectIDs used in request parameters or XML Access files.
It contains a subset of all the loaded ObjectIDs in memory. In so far it scales with the
number of ObjectIDs in the system, but not for all of these IDs the serialized version is
requested, hence the actual size is impossible to predict. The cache is used during every
request. Creating a cache entry is rather cheap. Typically all information can be retrieved
in memory, database lookups are scarcely necessary. A cache entry is fairly small.
M O D E L
The model caches can be categorized into two groups: One group of caches is accessed
during every portal request during page rendering. The second group of caches is especially
important for administrative actions. Hence those caches are especially important in those
environments where content and portal administration is done. Most run-time caches have
the name suffix live; the administrative caches have the suffix isolated.
