IBM 6.1.X manual We increased the lifetimes of all caches to at least one hour

￿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.

8 4

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