|
Most Web content from Enterprise applications, such as Oracle, PeopleSoft and Siebel, create dynamic web content. As a result, less than 20% of Enterprise Web application content can be cached or accelerated by conventional web cache and HTTP acceleration devices.
Web / application servers control caching of objects by including cache directives within the HTTP reply headers when communicating with client browsers. Here is an example server response header for an html page:
HTTP/1.1 200 OK
Date: Sat, 06 May 2000 18:06:07 GMT
Content-Type: text/html
Cache-control: private ¬ Cache in browser, not in network
The last line indicates that the content can be cached by the browser. However, the “Expires “ header is the basic way to set expiration of an object, for example, the following additional header line indicates when the object expires; until this time, the object can be cached but after the date noted below, the html object must be re-requested from the server:
Expires: Mon, 30 Oct 2000 14:19:41 GMT
If there no Expires header exists as above, Web caches may use a “Last-Modified” header to infer an expiration time.
However, the problem with dynamic content is that many Web caches will not cache an object at all if it doesn’t have a Last-Modified or an Expires header, and dynamically generated content rarely has either tag set. As a result, dynamic and secure objects cannot be cached. Finally, some content, such as cgi scripts, .jsp, .asp GET and POST methods simply are not cached because they may have side effects upon execution.
As a result, typically less than 20% of HTTP traffic is ever cacheable, severely limiting the performance benefits that can be obtained with traditional web caches. Cache administrators can over ride HTTP caching headers, but this must be done cautiously as it can directly impact application operation.
|
