I'm trying to test out the behavior of various options with sibling
peering, and noticing something that seems really strange in how squid
responds to ICP query when it has the object in it's cache, but the TTL is
under 30 seconds...
squidA and squidB are configured as siblings of each other, and each are
an accelerator for the same origin server. I have a test JSP on the
origin that logs every time it was hit and will output a Cache-Control
header dictated by query args.
If i execute something like the following...
curl -sD - 'http://squidA/test.jsp?cc=max-age=35' && \
curl -sD - 'http://squidB/test.jsp?cc=max-age=35'
...both requests are identical and generate a response with
"Cache-Control: max-age=35". i see in the logs that squidA makes an
ICP_QUERY to squidB, gets a UDP_MISS, then makes a FIRST_UP_PARENT request
returns the response and logs a TCP_MISS. Then the second curl command
hits squidB, squidA logs a UDP_HIT to the ICP_QUERY from squidB, and a
TCP_MEM_HIT that it returns to squidB which logs it as a SIBLING_HIT.
so far so good.
But if i change the max-age value returned to be 30 seconds...
curl -sD - 'http://squidA/test.jsp?cc=max-age=30' && \
curl -sD - 'http://squidB/test.jsp?cc=max-age=30'
...then when the second request gets send to squidB, squidA logs a
UDP_MISS for the URL, even though it just cached it, and will happily
generate a TCP_MEM_HIT for another 29 seconds.
The problem seems to be specific to the "freshness" (as opposed to the
original max-age) of the resource in the cache -- if it's less then 30
seconds, an ICP_QUERY generate a UDP_MISS. This one fails to get a
SIBLING_HIT just like the last example....
curl -sD - 'http://squidA/test.jsp?cc=max-age=40' && \
sleep 11 && curl -sD - 'http://squidB/test.jsp?cc=max-age=40'
Does anyone know if 30 seconds is a magic number when squid is replying to
ICP requests?
It's almost like squid figures that the content is going to expire in
"soon", so why bother acknowledging we have it to other caches -- except
that 30 seconds isn't really that soon.
-Hoss
Received on Thu Oct 01 2009 - 23:58:07 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 02 2009 - 12:00:02 MDT