Search squid archive

Re: TCP_REFRESH_HIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

Thanks


tookers wrote:

bergenpeak@xxxxxxxxxxx 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.


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux