Re: Cache size confusion

> As all the objects seem to expire NEVER that means that whatever I specify
> in the refresh rules has no effect. So the pages which ?I want to expire in
> 24 hours would not expire, then the question is what is the point of
> specifying the refresh rules. e.g I want www.cnn.com to expire in 12 hours
> but it is showing NEVER. Will cnn.com be refreshed after 12 hours or will
> the users get stale page. So do I make it expire in 12 hours.

        Again, the Expires field reported by cachemgr.cgi is reporting
the content's Expires header value. Many content providers do not put
any Expires header on their content; those that do often guess at a
value since it is hard, in general, to know the next moment in time that
a piece of content will be modified.

        The refresh rules in Squid are based upon the Alex protocol,
which takes into account the modification time, a minimum and maximum
age for a document, and an aging factor (all based upon the refresh
pattern regexp). The time to live in the cache is determined by how
long it has been since the last modification; the algorithm is described
thoroughly in the release notes. The Expires header field comes into
play as well: if the time in the Expired header has passed the document
is considered stale regardless of the refresh rules, and an IMS request
is made of the origin server.

        So in your case if you want to force your cache to check all
cnn.com pages after at most 12 hours you can use the refresh pattern

*.cnn.com 0 20 720

        WARNING: this pattern will refresh things like images as well,
which is probably not what you want (they hardly ever change). Note
that if a document has been modified recently the Alex protocol will
check its freshness with an IMS request before the full 12 hours passes.
Use caution with your refresh rules, you may be causing your users to
wait for unnecessary IMS checks on documents that have not changed. The
Alex protocol on its own does pretty well ...

        Hope that helps,

                             -- jad --
                          John Dilley <jad@hpl.hp.com>
Received on Wed Oct 28 1998 - 08:45:06 MST