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...

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:

For the third mechanism to be enabled...

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....

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...

...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