1 / 16

Portal Server Cache Settings

Portal Server Cache Settings. Plumtree 5.0.4 (BEA ALUI) March, 2007. 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

carnig
Download Presentation

Portal Server Cache Settings

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Portal Server Cache Settings Plumtree 5.0.4 (BEA ALUI) March, 2007

  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

  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

  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.

  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.

  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.

  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

  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.

  9. Data Collection & Analysis (2 of 7) • The portlet content cache used dramatically more RAM, as we had anticipated.

  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.

  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:

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

  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

  14. Data Collection & Analysis (7 of 7) • Far more private keys were created than public.

  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.

  16. Thanks for the Support! • And of course, thanks to all for their support as we collected this data.

More Related