Configuring the Caching Proxy to cache query responses
 Technote (troubleshooting)
 
Problem(Abstract)
How do I configure the Caching Proxy component to cache query responses?
 
Resolving the problem
You might want to cache the output from queries in reverse proxy or surrogate scenarios for the following reasons:
  • Help increase the servers cache hit ratio
  • Save load on the origin server and other back-end servers
  • Decrease the amount of network traffic.

You can cache queries in forward proxy scenarios, but it is generally not a good idea because doing so can risk serving stale data from the cache.

Also, because queries change frequently, an Internet Web site administrator might set the output of their queries to expire immediately, making those queries not candidates for caching.


How does HTTP 1.1 determine if a response is cacheable?
The Caching Proxy server decides if a particular response is cacheable by examining different components of the request and the response data streams. In particular it looks at the following components:
  • Request method
  • Response status code
  • Response Cache-Control headers
  • Response validator
  • Request authentication

The intricate details and mechanics of how HTTP determines if a response is cacheable is out of the scope of this document. For more information refer to RFC 1616.


Configuring the Caching Proxy to cache query responses
  1. Enable the CacheQueries directive in the ibmproxy.conf file:

    CacheQueries ALWAYS http://*
    # Query responses from all hosts
    # will be cached by the server if
    # the response is otherwise cacheable.

    CacheQueries PRIVATE http://*
    # Query responses from all hosts will be cached if
    # "Cache-Control: Public" header exists
    # in the response stream or if the response
    # Contains Cache-Control headers that force a
    # Revalidation for every request and the response
    # is otherwise cacheable.

  2. Set the CacheTimeMargin directive in the ibmproxy.conf file:

    CacheTimeMargin  2 minutes

    This directive instructs the proxy not to cache any documents that have an expiry date that is later than the time specified by this directive from the time the proxy receives it.

    Determining the value for this directive might involve some trial and error. Usually dynamic responses expire immediately or have very short expire times. Setting this value lower enables more documents to be cached.

  3. Set the CacheDefaultExpiry directive in the ibmproxy.conf file:

    CacheDefaultExpiry http:* 1 hour
    CacheDefaultExpiry ftp:* 5 days
    CacheDefaultExpiry gopher:* 2 days

    This directive specifies the expiry date for files that do not have an explicit expiry date or a last-modified date from which to compute an expiry date based on the CacheLastModifiedFactor directive.

    By default, HTTP is set to 0 because it is assumed that these type of responses are dynamic and are not supposed to be cached. Increase the value of the CacheDefaultExpiry directive so that the queries that qualify can be cached.

    Note: There is a risk of serving stale data when this is enabled.

  4. Set the CacheLastModifiedFactor directive in the ibmproxy.conf file:

    CacheLastModifiedFactor http://*/ 0.10
    CacheLastModifiedFactor http://*.htm* 0.20
    CacheLastModifiedFactor http://*.gif 1.00
    CacheLastModifiedFactor http://*.jpg 1.00
    CacheLastModifiedFactor http://*.jpeg 1.00
    CacheLastModifiedFactor http://*.png 1.00

    This directive sets the expiration for files that have a last-modified date but do not have an expiry date.

    The server uses the last modified date to determine how long since the file has been modified, then multiplies that time by the fraction value specified for this directive to determine the proportion of the age of the file to be used as its expiration. The higher this value is set, the longer the files reside in the cache without being revalidated. Setting the value too high causes stale data to be served.

  5. Enable the SignificantURLTerminator directive (optional):

    SignificantURLTerminator  &.

    This directive increases the cache hit ratio when you are certain that all the URLs with the same significant part return the same response from the server regardless of the values following the significant part.

    Note: Do not enable this unless you are sure that the same response will be returned. If this directive is enabled and the responses are not the same, inconsistent data is served from the cache.

  6. Enable the AgressiveCaching directive (optional):

    AgressiveCaching http://*

    This directive causes the proxy server to cache responses that are not ordinarily cached; for example, responses that contain the Cache-Control: no-cache header.

    Important note: Enabling this directive makes the Caching Proxy server non-HTTP 1.1 compliant.

Enabling Caching queries is beneficial in a reverse proxy scenario where the administrator has control over the content that is being served by the back-end server.

Enabling query caching in a forward proxy scenario can result in the serving of stale data and a minimal increase in the cache hit ratio because the administrator does not have any control over the content being served.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Edge Component
Operating system(s): Windows
Software version: 6.0.2
Software edition:
Reference #: 1179061
IBM Group: Software Group
Modified date: Nov 1, 2006