Caching

 


+ Search Tips   |   Advanced Search

 


Contents

  1. Caching pages shared by multiple users
  2. Cache scope
  3. Expiry time
  4. Cache scope and expiry time settings
  5. Default cache scope and expiry time settings
  6. Factors affecting cache scope and expiry time
  7. Limitations
  8. Security Issue
  9. Troubleshooting

See also

  1. WebSphere Portal Product Documentation Web site

 


Caching pages shared by multiple users

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

WebSphere Portal 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 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:

  • Public or shared cache:

    This type of caching provides the biggest performance improvement. A proxy server caches portal content and serves requests for the content. This caching eases the load on the portal server because requests that served by the proxy do not reach the portal. If most requests are for customized content, this type of caching provides no performance improvement. This type of caching should be used only for pages that contain public content that is not personalized. The following default values exist for portlet definitions, themes, and compositions if nothing is provided:

    • Remote cache scope is non-shared
    • Remote cache expiry is 0 seconds

  • Private cache (Web browser cache):

    This type of caching provides a much smaller performance improvement. The cache is typically located in each user's Web browser. This type of caching can be used for all content, including content that is personalized. By default, all portal content (both public and private) can be stored in a private cache.

 

Expiry time

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

  • Cache always expires: The content will never be cached in either a shared or a private cache

  • Cache never expires: The content can be stored indefinitely in either a shared or a private cache

  • Cache expires after this many seconds: The content will be stored for the number of seconds specified in either a shared or a private cache

 

Cache scope and expiry time settings

The following table lists the portal resources that contribute to the overall remote cache information on a page.

Resource Contributes Key Possible Values Set Via XML Access Set Via UI
Page remote cache scope remote-cache-scope SHARED, NON_SHARED yes yes
remote cache expiry 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 IgnoreAccessControlInCaches True, False yes yes

Example for XML access:

 <parameter name"remote-cache-scope">SHARED</parameter>
 <parameter name"remote-cache-expiry">3000</parameter>
 <parameter name"IgnoreAccessControlInCaches">true</parameter>

Resource Contributes Key Possible Values Set Via XML Access Set Via UI
Themes remote cache scope remote-cache-scope SHARED, NON_SHARED yes no
remote cache expiry 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"remote-cache-scope">SHARED</parameter>
 <parameter name"remote-cache-expiry">3000</parameter>

Resource Contributes Key Possible Values Set Via deployment descriptor or an extension to it Set Via UI
Portlet Definition remote cache scope remote-cache-scope SHARED, NON_SHARED yes yes
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 yes

The JSR 168 specification defines the meaning of the EXPIRATION_CACHE value. WebSphere Portal 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.

Resource Contributes Key Possible Values Set Via deployment descriptor or an extension to it Set Via UI
Portlet Window 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 JSR 168 specification defines the meaning of the EXPIRATION_CACHE value. WebSphere Portal 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.

Example code snippit for publishing the information at render time:

 String paramExpiry = "3000";
 String paramScope = "SHARED";
 renderResponse.setProperty( RemoteCacheInfo.KEY_SCOPE, paramScope );
 renderResponse.setProperty( RenderResponse.EXPIRATION_CACHE, paramExpiry );

Resource Contributes Key Possible Values Set Via XML Access Set Via UI
Portlet Wide Settings 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 NavigatorService.properties no
vary vary List of HTTP header fields that can be put into the vary response header No. Property in NavigatorService.properties no

 

Default cache scope and expiry time settings

The following table shows possible settings for...

wps_root/shared/app/config/services/NavigatorService.properties

Key Meaning Default value
public.session Specifies 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 portal performance.

false
public.expires Specifies the cache expiration time (in seconds) for the unpersonalized portal page. 60 sec
public.reload Specifies the time (in seconds) that unauthenticated pages reload. 60 sec
remote.cache.expiration Specifies the maximum cache lifetime of any page (both public and private). 60 sec
vary Specifies 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:

  • Cache scope and expiry time specified for the page

  • Cache scope and expiry time of the portlets on the page

    If any of the portlets on a page can only be cached in a private cache, then the entire page can only be cached in a private cache. A page cannot be stored in a shared cache unless all portlets on the page can also be stored in a shared cache. Make sure cache settings for portlets and pages are consistent.

  • Cache scope and expiry time of the theme

  • Global values as defined in the NavigatorServices.properties file, which is located in wps_root/shared/app/config/services

 

Limitations

  • For best results, use WebSphere Edge Server 5.2.0.16 or later for the proxy server. Previous versions do not serve multiple markup types from the same cache. If there are multiple requests for the same page, but with different markup, the cache is not used. WebSphere Edge Server 5.2.0.16 corrects this problem.

  • If your portal serves only one markup, make sure the vary is set appropriately. If your portal serves multiple markups, set the vary appropriately and use a larger cache size. Use remoteCacheInfo.response.header.vary = space separated list of other http header fields to appropriately set the vary.

    Enter any http header field names; use the HTTP 1.1 specification. The two most common http headers to specify here are vary = accept-language user-agent.

    The Vary value indicates the set of request-header fields that force a proxy to cache different variants of the same URL.

  • If your portal serves only one language, make sure the vary is set appropriately. If your portal serves multiple languages, set the vary appropriately and use a larger cache size. Use remoteCacheInfo.response.header.vary = accept-language to appropriately set the vary.

  • Only JSR portlets can override the cache lifetime setting at runtime. For more information, see Caching Portlet Output.

 

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 does not permit shared caching for authenticated pages. Use the Properties portlet or the XML configuration interface to override these default settings using the 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.

 

Troubleshooting

In general, 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:

  • Ensure that the cache settings for all portlets on the page are consistent with the cache settings for the page. For example, if one portlet on a page is set to only be cached in a private browser cache, then the entire page can only be cached in a private browser cache, and performance will not be optimal.

For the latest information about this topic, refer to the latest version of the WebSphere Portal Information Center at http://www.ibm.com/websphere/portal/library.

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.