Caching Techniques for IBM WebSphere Portal and WCM

I attended this session on caching techniques hosted by Joerg Huehne of IBM at the IBM Exceptional Web Experience Conference.  I always feel that caching is one of the very most important techniques for performance improvement opportunities in portal and this session reinforced it.  Some of the key takeaways from the session are below.

Overview and Goals  WebSphere Portal Caching

• Reduce number of requests to portal to
  • Save hardware and software licenses
  • Relieve load on back end services & databases
  • Save bandwidth
  • Speed up response
  • Increase throughput
• Can cache static content resources
• Greatly reduces bandwidth requirements
• Latency influences response time

This is all critical because portal just won’t work without caching.

Caching Layers

Browser

To make sure browser caching is enabled, make sure cache headers are modified in the web server to allow static resource caching of items such as images, javascript and CSS.

Edge Caching (proxy server)

• This is caching static resources at the proxy level
• IBM Edge Server components come with portal
  • Even if browser caching works fine, first request still served by portal
  • Geographically distributed cache proxies will move content closer to consumers

Adaptive Page Caching

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Caching benefits

• No hit on portal for cached pages – huge utilization gains possible
• Possible for shared and public pages if there is no public session
• Remember
  • Public cached content is published to the world
  • Remote caching of secure pages can be a security problem

Let portal decide what pages to cache and how

• Cache configuration can be assigned to individual pages and portlets
• Can set private, public or no-cache options
• Length of cache can be configured
• Configure page and portlet caching through portal administration or xmlaccess
• Theme can only be cached via xmlaccess
• Least common denominator of all caching meta-data of a page will be used to determine what is cached

ESI Caching

Caching of static resources on the plug-in of the Web Server

• Enabled by default but it is small so consider increasing it
• Caches static files in memory cache in HTTP plug-in
• Only non-secured content is cached
• Can be monitored using CacheMonitor on WebSphere Application Server (WAS)

Portlet Fragment Caching

This is caching of portlet markup.

• Must enable servlet caching on WAS
• Caching based on cache scope and cache expiration of portlets
• Delivers content without executing portal code
• Can cache shared portlets on protected pages
• Action requests invalidate cache
• URLs will be rewritten to match user’s state automatically but this has some overhead
• Configured via portlet administration, xmlaccess, or even pragmatically through the RenderResponse
• Can be monitored using CacheMonitor on WAS

For extended portlet caching options, a custom caching policy can be created using cachespec.xml.  This overcomes some of the limitations of the default portlet fragment caching options.

Object Caches

• Objects stored in DynaCache, including portal resources, access control, user data, etc.
• Portal does not replicate cache values
• Performance Monitoring Infrastructure (PMI) of WAS can be used to monitor caches
• Extended cache monitor can also be used
• This approach can easily be used in custom code, but note that you must be able to repopulate cache if cached data was evicted

WCM Caching

Leverages all levels of caching

• All public pages are cached in proxy
• JSR 286 portlet doesn’t require session on public pages
• Static resources from rendering servlet can be cached
• Portlet fragment caching can be used on portlets
• Caching can be tuned using the WCMConfigService
• Many internal caches are available – see the WCM tuning guide