2.1.2 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 or browser |
|
| At the Internet Service Provider (Akamai is an example) |
|
| In a caching proxy server located in front of the application servers |
|
| 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 home page is available and if this is true, the timestamp of the local copy in the browser cache is recorded.
This timestamp will be sent to the Web server in the following HTTP GET request. The browser might request the home page by specifying the requested URI as "/". In that same home 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 timestamped "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.
| Note: DynaCache does not do any processing of cache control headers. |
Server-side caching
Purpose built caching systems can be implemented between the client and the application server and 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 lower the overall costs of internet connections. A single proxy server can 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 in doing so, we can reduce the need to fetch the object directly from the source of origin.
Reverse proxy
Proxy caches can be placed directly in front of a particular server. The rationale behind this is to reduce the number of requests that the server must handle, thereby leaving it free to process new requests that it has not serviced before. A front-end server such as this is called a reverse proxy server to reflect the fact that it caches objects for many clients, but only on behalf of one server.