|
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
- 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.
|
|
- 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. |
|
- 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. |
|
- 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. |
|
- 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. |
|
- 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. |
|
|
|
|
|
|