IBM 6.1.X manual Com.ibm.wps.datastore.pageinstance.DerivationCache

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.

6 9

W E BS P HE R E P O R T AL V 6 . 1 T U N I N G G U I D E