Where caching is performed

There are several places where caching is performed.

In a typical IBM® WebSphere® topology, caching can be performed at several places. Some of the most notable caching locations are:
  • At the Web client and browser.
  • At the Internet Service Provider (Akamai is an example).
  • In a caching proxy server located in front of the application server.
  • In the HTTP Web server (for example, static content and edge side includes).
  • At the application server in DynaCache.
  • In the back-end database caching buffer pools.

Client-side caching

Caching capabilities are built in to most Web browsers today, and in that case, the cache works only for a single user. For example, the browser checks if a local copy of a Web page is available and if this is true, the time stamp of the local copy in the browser cache is recorded.

This time stamp will be sent to the Web server in the following HTTP GET request. The browser might request the Web page by specifying the requested URI as "/". In that same Web page request, the browser can use the HTTP header request field If-Modified-Since to indicate to the Web server that it already has a cached version that is time stamped "Sat, 10 July 200X 10:00:00 GMT."

The Web server checks the page modification time against the time specified in the HTTP request. The Web server determines that the page has not been modified since "Thurs, 6 May 200X 09:50:00 GMT," so it replies back to the browser that the page has not been modified. A return HTTP 304 response code is used to notify that a page has not changed since the specified date.

In this example, the Web server has indicated that the page has not been modified, so the browser cache entry is current. Therefore the browser displays the page from the cache. In this case, the browser also assumes that none of the images contained in the page has been modified.

Server-side caching

When caching systems are implemented between the client and the application server, they are known as proxy servers or proxy caches. Ideally, caches are placed as close to the client as possible without compromising security. DynaCache is an example of a server-side caching mechanism.

Proxy server caches are strategically placed near network gateways in order to reduce traffic, increase network bandwidth, and decrease the overall costs of network connections. A single proxy server can easily manage many users simultaneously while maintaining cached objects derived from many sources.

Most of the benefits are derived from caching objects requested by one client for later retrieval by another client. Several proxy servers can also be joined together into a cluster or hierarchy such that any cache can request items from a neighboring cache member, the assumption being that doing so reducesthe need to fetch the object directly from the source of origin.

Full Web page versus fragment caching

A fragment is a part or all of a rendered HTML page. Although a whole page may not be cacheable, it may contain sections of varying cacheability that can be separated into fragments and then cached independently. Any content that can be independently requested can be cached. This means that a fragment cannot depend on any information placed in its request scope by its parent or from other fragments. That means, if the parent object gets invalidated, the child object can be executed on its own. In the test environment, the Trade application does not make use of page fragments.

Static versus dynamic object caching

Most caching strategies target Web site content that rarely changes, such as graphical images and text files. However, many sites serve dynamic content, containing personalized information and data that change more frequently.

Caching dynamic content requires more sophisticated caching techniques. The IBM WebSphere Application Server DynaCache system provides an elegant solution in terms of caching dynamic content.