Caching
- Caching content
- Cache scope
- Expiry time
- Page scope and expiry
- Themes: scope and expiry
- Portlet Definitions: scope and expiry
- Portlet Windows: scope and expiry
- Portlet Wide: scope and expiry
- Default cache scope and expiry time settings
- Factors affecting cache scope and expiry time
- Limitations
- Security Issues
- Troubleshooting
Caching content
You can cache shared content on a proxy server such as WebSphere Edge Server.
Configure cache scope and expiry time by...
- page
- portlet
- theme
...using...
- XML configuration interface
- Manage Pages portlet
- Manage Portlets portlet
- Properties portlet
When caching JSR portlets, the cache scope is only for proxy server caching policies and requires the use of an edge server cache. Local display caching policies are not affected by this setting. The cache expiration setting is used for both local and remote caching policies.
Cache scope
The cache scope determines where the content will be cached. There are two types of caching:
- Shared cache across users:
Provides the biggest performance improvement. A proxy server caches content and serves requests for the content. Eases the load on the server because requests that are served by the proxy do not reach WebSphere 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.
Defaults:
- Remote cache scope is non-shared
- Remote cache expiry is 0 seconds
- Non-shared cache for a single user (Web browser cache):
Provides 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. If the computer is shared among multiple users, a user may see personalized content from other users if served from the browser cache. To prevent this from happening, do not enable private caching, even for personalize content.
Expiry time
How long the page is stored in a cache.Three options...
| Cache always expires | The content will never be cached in either a shared or a private cache.
Set the remote cache expiry to 0 |
| Cache never expires | The content can be stored indefinitely in either a shared or a private cache.
Set the remote cache expiry to -1 |
| 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.
Set the remote cache expiry to a positive integer up to 2^31 -1 |
Pages: scope and expiry
Resources that contribute to the remote cache information on a portal 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 | True, False | yes | yes |
Use Edit Page Properties to set page cache options...
- Cache Scope
- Cache Expiration
- Cache Access Control
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>
Themes: scope and expiry
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>
Portlet Definitions: scope and expiry
Resources that contribute to the overall remote cache information on a portlet definition...
| Contributes | Key | Possible values | Set via deployment descriptor | 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 |
WebSphere Portal uses EXPIRATION_CACHE 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.
Portlet Windows: scope and expiry
Remote cache information on a portlet window...
| Contributes | Key | Possible values | Set via deployment descriptor | Set via UI |
|---|---|---|---|---|
| remote cache scope | remote-cache-scope | SHARED, NON_SHARED | No. 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. Published during render time | No |
The portlet definition describes the portlet at a deployment time level given in the portlet deployment descriptor. 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 );
Portlet Wide: scope and expiry
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 | Time (in seconds) that unauthenticated pages reload. | 60 sec |
| remote.cache.expiration | Maximum cache lifetime of any page (both public and private). | 60 sec |
| vary | 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 Navigator Service in the IBM WAS Administrative Console.
Limitations
- For best results, use WAS Edge Components version 6.0.0.1 (or later), version 5.1.0.7 (or later), version 5.0.2.30 (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. These versions of WAS Edge Components correct this problem.
- If your WebSphere Portal serves only one markup, make sure the vary is set appropriately. If your WebSphere 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 WebSphere Portal serves only one language, make sure the vary is set appropriately. If your WebSphere 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.
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 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. 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 does not permit shared caching for authenticated pages. 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.
Troubleshooting
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:
- 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.
Parent topic
Configure portal behavior