Configure Edge Side Include caching

 

+

Search Tips   |   Advanced Search

 

Overview

The Web server plug-in contains a built-in ESI processor. The ESI processor can cache whole pages, as well as fragments, providing a higher cache hit ratio. The cache implemented by the ESI processor is an in-memory cache, not a disk cache, therefore, the cache entries are not saved when the Web server is restarted.

Edge Side Include (ESI) is configured through the plugin-cfg.xml file.

When a request is received by the Web server plug-in, it is sent to the ESI processor, unless the ESI processor is disabled. It is enabled by default. If a cache miss occurs, a Surrogate-Capabilities header is added to the request and the request is forwarded to the WAS. If servlet caching is enabled in the appserver, and the response is edge cacheable, the appserver returns a Surrogate-Control header in response to the WAS plug-in.

The value of the Surrogate-Control response header contains the list of rules that are used by the ESI processor to generate the cache ID. The response is then stored in the ESI cache, using the cache ID as the key. For each ESI include tag in the body of the response, a new request is processed so that each nested include results in either a cache hit or another request that forwards to the appserver. When all nested includes have been processed, the page is assembled and returned to the client.

The ESI processor is configurable through the WebSphere Web server plug-in configuration file plugin-cfg.xml. The following is an example of the beginning of this file, which illustrates the ESI configuration options.

<?xml version-"1.0"?>
<Config>
    <Property Name="esiEnable" Value="true"/>
    <Property Name="esiMaxCacheSize" Value="1024"/>
    <Property Name="esiInvalidationMonitor" Value="false"/>

 

Procedure

• The first option, esiEnable, can be used to disable the ESI processor by setting the value to false. ESI is enabled by default. If ESI is disabled, then the other ESI options are ignored.

• The second option, esiMaxCacheSize, is the maximum size of the cache in 1K byte units. The default maximum size of the cache is 1 megabyte.

  If the cache is full, the first entry to be evicted from the cache is the entry that is closest to expiration.

• The third option, esiInvalidationMonitor, specifies if the ESI processor should receive invalidations from the appserver.

ESI works well when the Web servers following a threading model are used, and only one process is started. When multiple processes are started, each process caches the responses independently and the cache is not shared. This could lead to a situation where, the system's memory is fully used up by ESI processor.

There are three methods by which entries are removed from the ESI cache:

• An entry expiration timeout occurs
• an entry is purged to make room for newer entries
• the appserver sends an explicit invalidation for a group of entries

For the third mechanism to be enabled, the esiInvalidationMonitor property must be set to true and the DynaCacheEsi application must be installed on the appserver. The DynaCacheEsi application is located in the installableApps directory and is named DynaCacheEsi.ear. If the ESIInvalidationMonitor property is set to true but the DynaCacheEsi application is not installed, then errors occur in the Web server plug-in and the request fails.

On distributed platforms, the cache for the ESI processor is monitored through the CacheMonitor application.

In order for ESI processor cache to be visible in the CacheMonitor, the DynaCacheEsi application must be installed as described above, and the ESIInvalidationMonitor property must be set to true in the plugin-cfg.xml file.

When WAS is used to serve static data, such as images and HTML on the appserver, the URLs are also cached in the ESI processor. This data has a default timeout of 300 seconds. You can change the timeout value by adding the property...

com.ibm.servlet.file.esi.timeOut

...to the JVM command line parameters. The following example shows how to set a one minute timeout on static data cached in the plug-in:

-Dcom.ibm.servlet.file.esi.timeOut=60

For information about configuring alternate URL, see Configure alternate URL.

 

Related tasks

Enabling the dynamic cache service
Task overview: Using the dynamic cache service to improve performance