If there is no or very little administration on your system and you have free memory in the Java heap available, it is safe to increase the lifetime of cache content to save the additional workload for reloading cached data.
Now we shall consider some recommendations for specific scenarios.
S M A L L N U M B E R O F P A G E S A N D S M A L L N U M B E R O F U S E R S
In this scenario a portal only has a limited number of pages and users accessing them. For example, there might be 200 pages in the system and up to a few hundred users working with the portal simultaneously. You will find portals of this kind often during development and testing or in smaller portal production systems.
For portals of this size and usage the default cache values typically are good. Hence only small modifications to the defaults given above should be required. Nevertheless you should be careful not to translate those cache settings directly into production for larger user communities.
S M A L L N U M B E R O F P A G E S A N D L A R G E N U M B E R O F U S E R S
In this scenario a portal only offers a rather small number of pages to the user. Overall there might be again only a few hundred pages, maybe with different access rights on them so that users might see only subsets of the pages. But in this scenario there are thousands of users accessing the system at the same time. In other words, thousands of users have active sessions.
Properties of caches that store information on pages typically do not need to be modified in this scenario. But all caches that store
We increased the sizes of the following nine caches in our measurement environments in such a way that the data of all concurrent users fits into the caches.
com.ibm.wps.model.factory.ContentModelCache.live
com.ibm.wps.ac.ExplicitEntitlements Cache.USER_GROUP
com.ibm.wps.model.factory.NavigationSelectionModelCache.live
com.ibm.wps.datastore.services.Identification.
SerializedOidString.cache
8 3