Configure Edge Side Include caching

 

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

The Web server plug-in contains a built-in ESI processor, which has the ability to 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 cycled.

The basic operation of the ESI processor is as follows: 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 the dynamic servlet cache is enabled in the appserver, and the response is edge cacheable, the application server returns a Surrogate-Control header in response to the WebSphere Application Server plug-in.

The value of the Surrogate-Control response header contains the list of rules which are used by the ESI processor in order 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 such that each nested include results in either a cache hit or another request forwarded 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"/>

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 whether or not the ESI processor should receive invalidations from the appserver. ESI works well when the Web servers following a threading model is 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: first, an entry's expiration timeout could fire; second, an entry may be purged to make room for newer entries; or third, the appserver could send an explicit invalidation for a group of entries. In order 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 will occur in the webserver plugin and the request will fail.

The ESI processor's cache can be monitored through the CacheMonitor application. In order for ESI processor's 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 your JVM's 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 more information about the plugin-cfg.xml file see "Using the dynamic cache service to improve performance."

For information about configuring alternate URL, see "Configuring alternate URL."

 

See Also

Enabling the dynamic cache service
Using the dynamic cache service to improve performance