© 2005 BEA Systems, Inc. | 1 Portal Server Cache Settings Plumtree (BEA ALUI) March, 2007

© 2005 BEA Systems, Inc. | 2 Topics High level results from last week’s monitoring of portlet content caching at client Caching technology overview Caching at client Modifications on two portal servers last Thursday Data collected from modified servers and two control servers Analysis of the data Next steps

© 2005 BEA Systems, Inc. | 3 Results from Last Week’s Monitoring Increased cache settings brought only small benefits In every measured category, performance was better—but not in a dramatic way Existing content cache settings may be acceptable Other cache settings (related to database queries rather than web requests) may still be improved

© 2005 BEA Systems, Inc. | 4 Caching technology overview (1 of 2) Portal servers request portlet content from the database and remote web servers Portal servers cache this content with configurable parameters such as cache size and number of objects. When the portal has cached content, it doesn’t need to make requests to the database or remote servers.

© 2005 BEA Systems, Inc. | 5 Caching technology overview (2 of 2) The cache is stored in portal server RAM. The portal tracks when cached content is used. When the cache is full, least frequently used cached content is dropped. Portlet code specifies public or private cache. Publicly cached content is shared between users; privately cached content is for one user only. Caching behavior can be monitored by PTSpy, an application tracing tool.

© 2005 BEA Systems, Inc. | 6 Caching at Client Client’s portal servers have much unused RAM, and this can be used for increased caching. Objective 1: Optimize portlet content caching on the portal application to reduce demands on network and remote portlet servers. Objective 2: Optimize caching of various portal objects (e.g. communities) to reduce demands on database. The monitoring last week studied Objective 1. Future monitoring might look at Objective 2.

© 2005 BEA Systems, Inc. | 7 Modifications Last Week Last week two production portlet servers ran portal cache settings that tripled the following values: Gadget Content Cache – Max Megabytes (set to 200) Gadget Content Cache – NumObjects (12,000) Gadget Object Cache – NumObjects (13,200) Plumtree Object Cache – NumObjects (15,000) The modified servers were WS-08 and WS-09

© 2005 BEA Systems, Inc. | 8 Data Collection & Analysis (1 of 7) PTSpy was configured to capture only INFO level messages from the Gadget Providers component. Data was captured on WS-06 and WS-07 (unmodified) and WS-08 and WS-09 (modified cache settings). Each server had the same CPU configuration. Results were analyzed from each machine during the same three-hour time period, to the second.

© 2005 BEA Systems, Inc. | 9 Data Collection & Analysis (2 of 7) The portlet content cache used dramatically more RAM, as we had anticipated.

© 2005 BEA Systems, Inc. | 10 Data Collection & Analysis (3 of 7) The modified servers cached better, but only slightly. They served more requests, created fewer new content requests (keys), and they had more fresh cache hits.

© 2005 BEA Systems, Inc. | 11 Data Collection & Analysis (4 of 7) Even when the modified portals did create new cache keys, they were less likely to have to create them more than once:

© 2005 BEA Systems, Inc. | 12 Data Collection & Analysis (5 of 7) We can see a dramatic improvement in some specific objects, for example, in header portlet cache keys:

© 2005 BEA Systems, Inc. | 13 Data Collection & Analysis (6 of 7) But the difference in header cache keys only improved performance for low use communities. High use communities such as the home page cached great on either the modified or control servers. The following portlets NEVER created a cache key during our monitoring on any server for the home page: Client Business Units Static Header Portlet

© 2005 BEA Systems, Inc. | 14 Data Collection & Analysis (7 of 7) Far more private keys were created than public.

© 2005 BEA Systems, Inc. | 15 Next Steps Improve portlet caching to increase cache hits: Identify portlets using private cache that should be public Identify portlets using inappropriately low cache times and raise them. Our monitoring focused on the portlet content cache that reduces requests to remote web servers. But the cache does other things too. PTSpy is able to monitor only database requests. We might analyze whether database queries can be reduced. This might have more punch. After client finish collecting data, you can decide whether to implement caching changes.

© 2005 BEA Systems, Inc. | 16 Thanks for the Support! And of course, thanks to all for their support as we collected this data.