ESI Processor | Prerequisites for ESI caching

ESI Best practices

+

Search Tips   |   Advanced Search

 

1. Fragment pages when necessary to efficiently edge cache parts of pages that are dependent on different subsets of parameters and attributes (where attributes have to be replaced by cookies).

2. Unlike the dynamic cache service that runs within the WebSphere Application Server, the ESI processor does not have access to user HTTP session data to uniquely identify page fragments.

   The application must be designed such that page fragments can be uniquely identified using request parameters in the request, including...

   • URL
   • HTTP form data
   • HTTP cookies

   In a JSP include, parameters should be included in the URL as query parameters instead of as JSP parameter tags. Since v6.0, WebSphere Commerce provides some cookies that can be used to access session data.

3. The parameter needs to be on the parent URL or the child URL.

   The child URL is created from the parameter passed into the JSP. Using WCParam within the JSP means that we cannot use it as a cache key, thus allowing the ESI processor visibility to these values as query parameters.

4. Consideration should be given as to how expensive a given fragment is to compute.

   Fragments that are expensive to compute provide the best candidates for edge caching and can provide significant performance benefits. The cache entry sizes for the ESI processor should be large enough to accommodate these expensive fragments. Also, the priority (or the time-to-live value) of these fragments should be raised to ensure that less expensive fragments are removed from the cache first. With ESI configured for the IBM HTTP Server Plug-in, we can use invalidation from Dynacache, so this is less of an issue. This can provide a huge performance boost. But you need to remember that the cache in the plug-in is only in memory. Also, it is important to note that the configuration at the servlet level does not let you define what is edgeable at a low enough level.

5. Another important consideration for edge caching is the update rate of a page.

   Invalidation of cached fragments is a relatively expensive operation. Therefore, very dynamic fragments that are invalidated often may not benefit from caching, and may actually hurt performance.

6. Web server tuning considerations when using ESI plug-in cache...
   • Use a thread-based model

   • Use a maximum of 1 GB for cache. This may cause issues if you are using the static memory cache as well.