On Thu, 24 Jan 2002, Bradley R. Smith wrote:
> I'm attempting to get the web-polygraph software working with
> Squid and am having trouble in that squid doesn't seem to think
> any of the content served up by polysrv is cacheable. The
> specifics are:
>
> OS => FreeBSD 4.4
> Squid => squid-2.4-200201240000
> Web Polygraph => polygraph-2.7.5
>
> Squid configuration is the stock squid.conf with "http_access deny
> all" replaced by "http_access allow all".
>
> Web Polygraph is the stock simple.pg with the server and robot
> address changes described in section "4. Adding a proxy" of the
> "Getting Started" document.
Short answer:
-------------
Please add Object Life Cycle parameters to your workload as
comments in simple.pg suggest:
// if you get no hits, set SimpleContent.obj_life_cycle to cntStatic, which
// is defined in workloads/include/contents.pg
After the above modification, your workload file may look like this:
#include "contents.pg" // include useful objects
...
Content SimpleContent = {
size = exp(13KB);
cachable = 80%;
obj_life_cycle = cntStatic; // use simple OLC parameters
};
...
Long answer:
------------
By default, Squid is picky about caching responses without so called
"validators" such as a Last-Modified header. To be precise, Squid will
not cache an object that it cannot validate if that object becomes
stale within 60 seconds. This optimization/heuristics is hard-coded
and is probably not documented. See refreshIsCachable() in
src/refresh.c and thank Duane Wessels for digging this up for me:
Simple.pg is the minimum configuration that can be used to run a test
with hits. It has no Object Life Cycle model configured, and, hence,
the servers do not generate Last-Modified headers or any other HTTP
validators.
The '60-second age' in the debugging output is somewhat misleading
without reading the Squid sources. The age is actually computed from
the the future point of view (60 seconds ahead of us, see the
heuristic above). This is a useful coding trick, but I am not going to
waste your time explaining the rationale.
Hope this clarifies,
Alex.
> After much prowling around I believe the following is the smoking gun
> from the squid cache.log (with debugging turned on):
>
> 2002/01/24 11:45:32| refreshCheck: 'http://10.10.20.11:9090/w05ef1a0e.3c8d1bf6:0
> 0000004/t01/_00000001'
> 2002/01/24 11:45:32| STALE: age 60 > min 0
> 2002/01/24 11:45:32| Staleness = 60
> 2002/01/24 11:45:32| refreshCheck: Matched '<none> 0 20% 259200'
> 2002/01/24 11:45:32| refreshCheck: age = 60
> 2002/01/24 11:45:32| check_time: Thu, 24 Jan 2002 19:46:32 GMT
> 2002/01/24 11:45:32| entry->timestamp: Thu, 24 Jan 2002 19:45:32 GMT
> 2002/01/24 11:45:32| storeExpireNow: 'C5E9BA874EABEE74D17652C3077D9A37'
>
> that was generated in response to the following HTTP reply:
>
> 2002/01/24 11:45:32| httpProcessReplyHeader: key 'C5E9BA874EABEE74D17652C3077D9A
> 37'
> 2002/01/24 11:45:32| ctx: enter level 0: 'http://10.10.20.11:9090/w05ef1a0e.3c8
> d1bf6:00000004/t01/_00000001'
> 2002/01/24 11:45:32| GOT HTTP REPLY HDR:
> ---------
> HTTP/1.0 200 OK
> Cache-Control: public
> Date: Thu, 24 Jan 2002 19:45:32 GMT
> Content-Length: 3957
> X-Target: 10.10.20.11:9090
> X-Xact: 05ef1a06.60f60726:00000002 05ef1a0e.3c8d1bf6:7ffffff7
> X-Abort: 1412400744 2082554117
> X-Phase-Sync-Pos: 0
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:21 MST