Filter
Top Products
83
WEBSPHERE PORTAL V6.1 TUNING GUIDE
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 user-dependant information might be a problem.
Assume you have 2000 active users in your system. Per-user caches being sized to only
1000 entries will operate at their upper limit nearly all of the time and constant re-calculating
or re-loading of data from the portal database will the consequence. You should size the
user-dependent caches in a way such that enough entries for the number of currently active
users can remain in memory. We define the number of ‘currently active users’ as those who
have a session and still issue requests against WebSphere Portal. By contrast there are
passive users who still have a session, but no longer issue requests and have forgotten to
log out or simply went away from the screen and let the session time out.
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