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.
Contents
General Comments
Small Number of Pages and
Small Number of Users
Small Number of Pages and
Large Number of Users
Portals with
Long Session Timeouts
Portals with Many
Pages
GENERAL COMMENTS
Most portal caches fall into one of four groups:
- Caches where the number of entries scales with the number of active
users. For example, the following access control user context cache:
com.ibm.wps.ac.AccessControlUserContextCache
- Caches where the number of entries scales with the number of users using
a specific function. For example, the following
cache:
com.lotus.cs.services.directory.ldap.BasicLDAPDirectoryService.user<
/code>.
- Caches which scale with the number of pages being visited. For example,
the following resource cache:
com.ibm.wps.model.content.impl.ResourceCache.
- Caches which scale based on the growth of some other resource, such as
URL mappings, which are stored in the following 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.
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.
SMALL NUMBER OF PAGES AND SMALL NUMBER OF
USERS
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.
SMALL NUMBER OF PAGES AND LARGE NUMBER OF
USERS
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<
/tt>
- com.ibm.wps.puma.OID_User_Cache
- com.ibm.wps.puma.DN_User_Cache
- com.ibm.wps.puma.OID_DN_Cache
- com.ibm.wps.puma.DN_Group_Cache
- com.ibm.wps.puma.OID_Group_Cache
We increased the lifetimes of all caches to at least one hour.
PORTALS WITH LONG SESSION TIMEOUTS
If the session timeout has a high value, it is likely that there will be a
large number of users who still have sessions with the portal, but who have not
interacted with the site for a significant period of time. These users are
known as passive users, and they can cause some special performance
challenges.
In this situation the number of sessions can be much larger. But typically
many of these sessions are ‘passive’. It is typically not necessary to have all
information in memory for all these users when they leave their desk but not
the portal, for example during lunch. To find proper sizes for the portal
caches you need a good understanding on the behavior of your users. Users who
have not worked with the portal for more than an hour typically will accept
response times of two or three seconds for their first request after such a
long break, whereas users who work with the portal rather constantly do not
want to see their data being evicted from caches.
For this scenario it is hard to give precise cache size recommendations. The
values simply depend too much on your portal usage scenario. You have to
monitor your system and users closely to determine good values.
PORTALS WITH MANY PAGES
Portals in this group have several thousand pages that are available for
larger groups of users and therefore are potentially accessed quite frequently.
We do not count installations with many customized pages (sometimes known as
implicit derivations) to this group because these are private
resources and are loaded for the current user only. Private data is not added
to the shared portal caches.
For example, your portal could have 5000 pages in total. Half of those are
available to all users; on the other half there are several user groups who
have view rights, other have manage right on those pages. In this case you
typically do not want to have all pages and all corresponding information in
memory at all times. But you want to make sure that all frequently accessed
data is in memory. Typically not all portal pages are accessed equally
frequently. The better your page view statistics are, the easier it is for you
to tune the portal caches.
We increased the sizes of the following caches in our measurement
environments so that all frequently-accessed pages, which depend on our
scenario, can be cached.
- com.ibm.wps.datastore.pageinstance.OIDCache
- com.ibm.wps.datastore.pageinstance.DerivationCache
- com.ibm.wps.model.factory.ContentModelCache
- com.ibm.wps.model.factory.NavigationSelectionModelCache
- com.ibm.wps.ac.PermissionCollectionCache
- com.ibm.wps.ac.ProtectedResourceCache
- com.ibm.wps.ac.ExplicitEntitlementsCache.USER_GROUP
- com.ibm.wps.datastore.services.Identification.SerializedOidString
We increased the lifetimes of all caches to at least one hour.
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.