IBM 6.1.X manual Example Scenarios

Models: 6.1.X

1 97
Download 97 pages 55.38 Kb
Page 87
Image 87
Example Scenarios

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.

8 2

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

Page 87
Image 87
IBM 6.1.X manual Example Scenarios