sets of access control rights on these pages. This cache contains very ‘valuable’ information; it utilizes several other caches, for example, page instance and access control caches, to build its data. Hence creating a cache entry usually only requires in- memory information, but can also lead to many database queries. The size of an entry in the cache depends on the complexity of the pages, but typically the objects are medium- sized, since they are usually made of references to other cached data. The cache should be large enough to hold the most frequently accessed pages multiplied with the number of different access control settings on these pages. Increasing the cache lifetime can be useful if page definitions do not change often in your environment.
Example: A portal has 500 pages and all users have the same permissions on these. In addition there are another 50 pages; two groups of users have different access rights on these pages. In this case a maximum of 600 entries would be in the cache.
com.ibm.wsp.mode.content.impl.TopologyCache
Default size: 10000, default lifetime: 5700, usage pattern: regular.
This cache contains portal topology information, i.e. portal navigation elements being composed of navigation nodes and their sorted, access control-filtered children. Topology elements undergo several processing steps from first loading from the database until finally being added to the cache. This cache only contains the completely processed topology entities. This cache is explicitly used during login and whenever a user navigates to a part of the portal where he has not been before during the same session. If a cache entry is not found, a private copy is created that is then further processed. Once the private copy is completely processed -that does not happen for all navigation nodes- it is added to the cache. If a user finds an entry in the cache a reference is copied into his private topology model and additional cache accesses are no longer necessary. Hence there is only one cache hit (or miss) per user and navigation node. The cache scales with the number of navigation nodes and the number of different sets of permissions on these and, possibly, the derivation chain (children and parents) a page belongs to. Entries in this cache are expensive to create; they rely on other cached information, like the access control caches and the page instance cache. The entries in the cache are medium-sized, being mainly some lists of references to other cached data. The cache should be sized in a way such the most important pages multiplied with all the different sets of permissions that exist on theses page can be stored.
com.ibm.wps.model.factory.ContentModelCache.live
Default size: 1000, default lifetime: infinite, usage pattern: regular.
This run-time cache contains the content models for portal users. There is one entry per active portal user. The cache should be large enough to hold all models for these users. An entry in the cache has the maximum lifetime of the corresponding user session, i.e. entries are removed at the end of the session. Creating a cache entry can be very expensive. Typically all required information is in memory, but accessing the database, also many times, might be necessary if underlying information is also no longer cached. Furthermore the number of pages summarized in the model can be very large which
7 1
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
