Using WebSphere Portal remote caching Support

The WebSphere® Portal product provides remote cache support, with which IBM® Mobile Portal Accelerator pages can be explicitly configured to be cached remotely by a reverse proxy server or through the browser cache.

Purpose

A reverse proxy that adheres to the HTTP/1.1 (rfc2616) specification for Cache-Control and Vary headers is required for remote cache support. If you are using WebSphere Application Server Edge Components as the reverse proxy, you will need to install WebSphere Application Server Edge Components and edit the /ibmproxy.conf file.

Note:

See the Caching topic in the WebSphere Portal product documentation for more details about the configuration options available for page caching.
See the WebSphere Application Server Edge Components information center for more information on installing WebSphere Application Server Edge Components.

Install WebSphere Application Server Edge Components

Note: WebSphere Application Server Edge Components may not be available on the IBM Support website. Contact IBM Support for more information if you need assistance finding the correct component version to download.

Edit the /ibmproxy.conf file

Insert the proxy rules after this line:

# *** START NEW MAPPING RULES SECTION ***
ReversePass http://<fully_qualified_WP_Hostname>:<WP_port>/<WP_context_root>/* http://<fully_qualified_Proxy_hostname>/<WP_context_root>/*

Proxy /<WP_context_root>/* http://<fully_qualified_WP_Hostname>:<WP_port>/<WP_context_root>/*

For example:

# *** START NEW MAPPING RULES SECTION ***
ReversePass http://wp.acme.com:10038/wps/* http://proxy.acme.com/wps/*
Proxy /wps/* http://wp.acme.com:10038/wps/*

Change the CacheTimeMargin directive to 1 minute. This allows longer-lived objects (those over one minute) to be cached:
```
CacheTimeMargin  1 minutes
```
Add the following directives:
```
SupportVaryHeader on
RegisterCacheIdTransformer Cookie JSESSIONID
```
Note: Because the RegisterCacheIdTransformer is configured to use the Cookie JSESSIONID, the “Cookie” value should be removed from the Vary property in wp_root/shared/app/config/services.properties.

Restrictions

Mobile Portal Accelerator does enforce some restrictions beyond what is supported by WebSphere Portal:

By default, the Mobile Portal Accelerator theme defined for all XDIME pages has been modified with remote-cache-expiry of -1 (unlimited) and remote-cache-scope of shared (cacheable by reverse proxy servers).
The wp_profile_root/PortalServer/config/NavigatorService.properties file has been updated to include Vary: User-Agent, Cookie. The Cookie option for the Vary property causes reverse proxy servers to cache pages based on the URL and the user's session. This enforces uniqueness among the cached pages so that pages are never shared even though a page is configured for “Shared cache across users”.
Note: If using WebSphere Application Server Edge Components as directed in the prerequisite section, it is not necessary to include the Cookie value. It is recommended that you remove the Cookie value for performance reasons.
Cache settings are not confined to a single markup. Therefore if a page or portlet is HTML and XDIME capable then the remote cache settings would be applied to both the HTML and XDIME aggregator. It is not possible to define separate settings.
The remote cache settings for a page is determined by querying all components of a page which includes the global settings, the aggregator, and all portlets on the page. The lowest common denominator is used for the remote cache settings. Although minimized portlets do not contribute content, their remote cache settings do contribute to the overall remote cache settings of the owning page.
A Preload Notice configured for a page will disable remote cache settings for both itself and the parent page. The cache settings for both pages are set for Cache Expiration to Cache always expires.
Note: An administrator can re-enable the remote cache settings but this may result in undesirable caching behavior.
A Preload Notice configured for a portlet will have the remote cache settings disabled by setting the remote-cache-expiry=0 for the portlet. However, if a portlet has remote-cache-dynamic=true, then it is possible for the portlet to override this setting dynamically at runtime to enable remote caching for the portlet on a page. If a Preload Notice is configured for the portlet, it is possible that the Preload Notice content will be cached instead of the portlet content. It is recommended that a Preload Notice not be configured for portlets with remote-cache-dynamic=true to avoid this situation. If a Preload Notice is configured, then caution should be taken to understand if the portlet will change the remote cache settings dynamically.
Note: An administrator can re-enable the remote cache settings but this may result in undesirable caching behavior.