Caching strategy

When determining a caching strategy for WebSphere Commerce, there are several key issues to resolve.

• Which pages should be cached

• Where caching should take place

• Cache full pages or page fragments

• How to invalidate the cached data

 

Which pages should be cached

When determining which Web pages should be cached, good candidates for caching are pages that:

• Are accessed frequently

• Are stable for a period of time

• Contain a majority of contents that can be reused by a variety of users

A good example would be catalog display pages.

 

Where caching should take place

Theoretically, caching should take place in the tier closest to the user. In reality, other factors such as security and user specific data may influence the choice of the best place to cache the content. To maximize the benefit of dynamic caching, elements of a page should be fragmented as finely as possible so that they can be cached independently in different cache entries.

For example, the non-user specific, non-security sensitive fragments are generally useful to many users, and can be cached in a more public space and closer to the user. The security sensitive data should be cached behind the enterprise firewall.

Caching outside of WAS may be used with larger databases and sites to improve performance. Edge Server and the ESI cache-plugin is provided with WAS to provide extra caching capability. Session information (language ID, preferred currency ID, parent Organization, contract ID, and member group) must be stored in session cookies in order for caching to be done on a server external to WAS.

 

Cache full pages or page fragments

All Web pages consist of smaller and often simpler fragments. An example of a page fragment could be a header, sidebar, footer or an e-Marketing Spot. Breaking a Web page into fragments or components makes more caching possible for any page, even for personalized pages. Fragments should be designed to maximize their reusability.

Caching a whole Web page simply means that the entire page is cached as big cache entry including all the content from all fragments that have no includes or forwards. This can save a significant amount of application server processing and is typically useful when the external HTTP request contains all the information needed to find the entry.

If Web pages are broken into different fragments and the fragments are cached individually, then some fragments may be reused for a wider audience. When a Web page is requested, then different fragments are reassembled to produce the page. For more information see Full page and fragment caching.

If the page output has sections that are user-dependent, then the page output is cached in a manner known as fragment caching. That is, the JSP pages are cached as separate entries and will be reassembled when they are requested. If the page output always produces the same result based on the URL parameters and request attributes, then this output can be cached with the cache-entry using the property consume-subfragments (CSF) , and the WebSphere Commerce's store controller servlet (com.ibm.commerce.struts.ECActionServlet) as the servlet name.

Web pages can be cached using full page caching or fragment caching or a combination of both methods.

 

Related Concepts

Cache identifiers
Cache invalidation
Configure the dynamic cache service in cachespec.xml
Edge caching

 

Related tasks

Configure cacheable objects

 

Related Reference

Caching defaults