Filter
Top Products
84
WEBSPHERE PORTAL V6.1 TUNING GUIDE
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.
P O R T A L S W I T H L O N G S E S S I O N T I M E O U T S
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.
P O R T A L S W I T H M A N Y P A G E S
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.