IBM WEBSPHERE 6.1.X - Manual (Page 87)

8 2
W E B S P H E R E P O R T A L V 6 . 1 T U N I N G G U I D E
Example Scenarios
This section describes some example usage scenarios along with descriptions of possible
cache settings and suggested cache sizes. This discussion may be useful as starting point
for the caches in your environment.
G E N E R A L C O M M E N T S
Most portal caches fall into one of four groups:
1. Caches where the number of entries scales with the number of active users. For
example, the access control user context cache (
com.ibm.wps.ac.
AccessControlUserContextCache ) falls into this category.
2. Caches where the number of entries scales with the number of users using a
specific function. For example, the cache
com.lotus.cs.services.
directory.ldap.BasicLDAPDirectoryService.user falls into this
category.
3. Caches which scale with the number of pages being visited. The resource cache
(
com.ibm.wps.model.content.impl.ResourceCache ) is an example of
this type.
4. Caches which scale based on the growth of some other resource, such as URL
mappings, which are stored in the cache
com.ibm.wps.model.factory.
URLMappingCache.live .
Those that scale on portal resources should have lifetimes and sizes based on the number
of portal resources in the system and how frequently users access these resources. The
other caches depend upon usage scenarios such as those described in this section.
Most caches have a lifetime associated with them because the cached content might
change over time. For example, access control information could be changed via user
administration in the administrative portlets, XML Access or the WebSphere Portal scripting
interface. All code that uses caches within WebSphere Portal is implemented in a way such
that cache entries that are no longer valid are removed from the cache if the corresponding
information has been changed or deleted. The lifetime therefore is used for three reasons:
Expired cache entries can be removed to free up memory.
There are rare race conditions in cluster setups so that invalidation events are
processed correctly but the cache still reflects wrong data.
Updates within external systems, like an external access control system, will never
become visible.