Set Edge Side Include caching

 

+

Search Tips   |   Advanced Search

 

The Web server plug-in, plugin-cfg.xml, contains a built-in Edge Side Include (ESI) processor that creates an in-memory cache for whole pages and fragments of pages. Cache entries are not saved when the Web server is restarted.

The ESI processor enabled by default.

If a cache miss occurs, a Surrogate-Capabilities header is added to the request and the request is forwarded to WAS.

If servlet caching is enabled in the appserver, and the response is edge cacheable, WAS returns a Surrogate-Control header.

The Surrogate-Control response header contains rules used by the ESI processor to generate the cache ID. The response is 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 in plugin-cfg.xml. For example...

<?xml version-"1.0"?>

<Config>
    <Property Name="esiEnable" Value="true"/>
    <Property Name="esiMaxCacheSize" Value="1024"/>
    <Property Name="esiInvalidationMonitor" Value="false"/>

...where...

esiEnable	ESI is enabled by default. To disable, set to false. If disabled, other ESI options are ignored.
esiMaxCacheSize	Maximum size of the cache in 1K byte units. Default maximum size is 1 MB. If the cache is full, the first entry to be evicted from the cache is the entry that is closest to expiration.
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:

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

For the third mechanism to be enabled...

• esiInvalidationMonitor property must be set to true
• 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 the ESI processor cache to be visible in the CacheMonitor....

• ESIInvalidationMonitor property must be set to true
• DynaCacheEsi application must be installed on the appserver

When WAS is used to serve static data, such as images and HTML, the URLs are also cached in the ESI processor. This data has a default timeout of 300 seconds. We 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

You can set an alternate URL.

 

Related tasks

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