On Wed, 14 Oct 2009 09:48:45 -0600, "bergenpeak_at_comcast.net"
<bergenpeak_at_comcast.net> wrote:
> Thanks. Right now I have the squid content "ttl" set to 3600. However,
> I think either the client is sending a "Cache control max-age=X" (where
> X is < 3600) or where the origin server is providing the object to squid
> with some cache control or equiv attributes to some value << 3600 which
> is forcing squid to reverify the content hasn't changed. I'm trying to
> determine if the issue is a client setting or origin server setting
> which is (apprently) overriding the squid setting. Wondering what
> knobs/tools exist within squid to see information about whether the
> object is "fresh" or "stale".
There is no such reporting for individual objects in Squid.
Enter the URL at http://www.redbot.org to scan the web server properties.
Amos
>
> Thanks
>
>
> tookers wrote:
>>
>> bergenpeak_at_comcast.net wrote:
>>
>>> Is there a way to look at the object cache in squid and determine the
>>> current "freshness" of the content?
>>>
>>> I've got content in the squid cache where I would expect the content
to
>>> be a "TCP_HIT". Looking in the squid access.log, I see the access to
>>> the object being reported as "TCP_REFRESH_HIT". I'm trying to
>>> understand if it's something in the client request or something in how
>>> the original object was served up by the origin server which is
causing
>>> squid to re-verify with the origin server that the object hasn't
>>> changed.
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>
>> Hi there,
>>
>> The Squid docs state that TCP_REFRESH_HIT is when an object is in cache
>> but
>> is STALE, the IMS (if-modified-since) query results in a '304 - not
>> modified'. So the object is cached but has reached the max-age (e.g. 60
>> secs), Squid then checks on the back-end to see if a fresh version of
the
>> file exists. It comes back with status 304 because the object in cache,
>> and
>> on the back-end, are the same. If you are seeing lots of
TCP_REFRESH_HIT,
>> and the file isn't updated very often, it may be worthwhile increasing
>> the
>> cache time.
>>
>> HTH.
>>
Received on Thu Oct 15 2009 - 00:36:44 MDT
This archive was generated by hypermail 2.2.0 : Thu Oct 15 2009 - 12:00:03 MDT