WebSphere

 

Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

 

Caching

This topic has techniques that can improve the caching performance of IBM® WebSphere® Portal Express.

For additional tips to improve WebSphere Portal Express performance, see the WebSphere Portal Express Tuning Guide. Tuning guides for various versions of WebSphere Portal Express are available at http://www.ibm.com/websphere/portal/library.

 

Caching pages shared by multiple users

If you use a proxy server such as WebSphere Edge Server and your system has content that can be shared among multiple users, you can improve performance by caching this shared content.

WebSphere Portal Express allows you to configure the cache scope and the cache expiry time of the specified content. The cache scope and cache expiry time are configured by page, portlet, and theme. WebSphere Portal Express combines this information to produce a final cache scope and expiry time for each page it serves. You can configure these cache settings in one of the following two ways:

 

Cache scope

The cache scope determines where the content will be cached. There are two types of caching:

 

Expiry time

The expiry time determines how long the page is stored in a cache. WebSphere Portal Express allows three options for specifying expiry time:

 

Cache scope and expiry time settings

The following table lists the resources that contribute to the overall remote cache information on a Page:

Contributes Key Possible Values Set Via XML Access Set Via UI
remote cache scope com.ibm.portal.remote-cache-scope SHARED, NON_SHARED yes yes
remote cache expiry com.ibm.portal.remote-cache-expiry Time in seconds, given as an integer between -1 and the value ((2 to the power of 31)-1)

Use the value -1 if you never want the cache to expire.

yes yes
Ignore Access Control in Caches com.ibm.portal.IgnoreAccessControlInCaches

See Security Issues for more information.

True, False yes yes

Example for XML access: 

	<parameter name"com.ibm.portal.remote-cache-scope">SHARED</parameter>
	<parameter name"com.ibm.portal.remote-cache-expiry">3000</parameter>
	<parameter name"com.ibm.portal.IgnoreAccessControlInCaches">true</parameter>
The following table lists the resources that contribute to the overall remote cache information for Themes:

Contributes Key Possible Values Set Via XML Access Set Via UI
remote cache scope com.ibm.portal.remote-cache-scope SHARED, NON_SHARED yes no
remote cache expiry com.ibm.portal.remote-cache-expiry Time in seconds, given as an integer between -1 and the value ((2 to the power of 31)-1)

Use the value -1 if you never want the cache to expire.

yes no

Example for XML access: 

	<parameter name"com.ibm.portal.remote-cache-scope">SHARED</parameter>
	<parameter name"com.ibm.portal.remote-cache-expiry">3000</parameter>
The following table lists the resources that contribute to the overall remote cache information on a Portlet Definition:

Contributes Key Possible Values Set Via deployment descriptor or an extension to it Set Via UI
remote cache scope remote-cache-scope SHARED, NON_SHARED yes no
expiration cache EXPIRATION_CACHE Time in seconds, given as an integer between -1 and the value ((2 to the power of 31)-1)

Use the value -1 if you never want the cache to expire.

yes yes
remote cache dynamic remote-cache-dynamic True, False yes no

The Standard Portlet API specification defines the meaning of the EXPIRATION_CACHE value. WebSphere Portal Express uses this value to determine the lifetime of the portlet's output in a remote cache, just like the remote cache expiry for themes. The remote cache dynamic setting is an optimization to notify the container whether a portlet window can publish remote cache information at render time. The deployment descriptor specification shows how to deal with these settings. The following table lists the resources that contribute to the overall remote cache information on a Portlet Window:

Contributes Key Possible Values Set Via deployment descriptor or an extension to it Set Via UI
remote cache scope remote-cache-scope SHARED, NON_SHARED no, only published during render time no
expiration cache EXPIRATION_CACHE Time in seconds, given as an integer between -1 and the value ((2 to the power of 31)-1)

Use the value -1 if you never want the cache to expire.

no, only published during render time no

The portlet definition describes the portlet at a deployment time level given in the portlet deployment descriptor. Thus, attributes specified in the deployment descriptor are valid on all occurrences on all pages of this portlet. The portlet window describes the runtime entity for a portlet. While in the rendering phase of a portlet, the portlet can publish values or attributes via an API. Thus, attributes specified while rendering the portlet is portlet instance specific. Example code snippet for publishing the information at render time: 

	String paramExpiry = "3000";
	String paramScope = "SHARED";
	renderResponse.setProperty( "portlet.remote-cache-scope", paramScope );
	renderResponse.setProperty( RenderResponse.EXPIRATION_CACHE, paramExpiry );
The following table lists the resources that contribute to the overall remote cache information on Portlet Wide Settings:

Contributes Key Possible Values Set Via XML Access Set Via UI
remote cache expiration remote.cache.expiration Time in seconds, given as an integer between -1 and the value ((2 to the power of 31)-1)

Use the value -1 if you never want the cache to expire.

no, property in WP NavigatorService no
vary vary List of HTTP header fields that can be put into the vary response header no, property in WP NavigatorService no

 

Default cache scope and expiry time settings

The following table shows possible WP NavigatorService settings:

Key Meaning Default value
public.session Whether an anonymous user always has a session, which may be useful when a portlet requires a session for anonymous users.

Setting public.session to true reduces performance.

false
public.expires The cache expiration time (in seconds) for the unpersonalized page. 60 sec
public.reload The time (in seconds) that unauthenticated pages reload. 60 sec
remote.cache.expiration The maximum cache lifetime of any page (both public and private). 60 sec
vary The HTTP headers that force a proxy to cache different variants of the same URL. Accept-Language user-Agent

 

Factors affecting cache scope and expiry time

Multiple factors can affect the cache scope and expiry time for a page. The remote-cache-scope and remote-cache-expiration of a rendered page view is calculated as the minimum of the following factors:

 

Limitations

With the above settings, it is possible to generate an HTTP response header like Cache-Control: max-age=-1, which indicates an unlimited cache expiration when a page is rendered. This is beyond the HTTP 1.1 specification but if a proxy cache does not support an unlimited cache expiration, WebSphere Portal Express supports it. If the cache infrastructure does not properly work with this response header, set the remote.cache.expiration value in the WP NavigatorService to a large value as described in Setting configuration properties. To set an unlimited cache expiration is not possible if the cache infrastructure does not support it.

 

Security Issues

Storing authenticated pages in a shared cache introduces security holes. If a malicious user discovered the URL for an authenticated page, that user could read pages containing private information. By default, WebSphere Portal Express does not permit shared caching for authenticated pages. You can use the Properties portlet or the XML configuration interface to override these default settings using the com.ibm.portal.IgnoreAccessControlInCaches parameter, but in most cases this is not recommended.

In some rare circumstances, it might be useful to store authenticated pages in a shared cache. For example, if all authenticated users receive identical content, then storing authenticated pages in a shared cache might be acceptable.

 

Troubleshoot

In general, you should monitor the cache hit rate on the proxy server and adjust the cache size appropriately. If the hit rate is lower than expected, increase the cache size. You can also check the following item:

 

Parent topic:

Tuning