Re: [squid-users] Re: refresh_pattern question

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 31 Dec 2009 17:57:34 +1300

Manjusha Maddala wrote:
> On Wed, 2009-12-23 at 18:10 -0800, RW wrote:
>> On Wed, 23 Dec 2009 16:34:37 -0800
>> Manjusha Maddala <mmaddala25_at_nextag.com> wrote:
>>
>>> >From "Squid - the definitive guide", a simplified description of the
>>> refresh_pattern algorithm is:
>>>
>>> - The response is stale if the response age is greater than the
>>> refresh_pattern max value.
>>> - The response is fresh if the LM-factor is less than the
>>> refresh_pattern percent value.
>>> - The response is fresh if the response age is less than the
>>> refresh_pattern min value.
>>> - Otherwise, the response is stale.
>>>
>>> The webserver I have neither sends a Last-modified header nor an
>>> Expires header.
>> That's odd, if you don't have Last-Modified, or an equivalent header,
>> you shouldn't see TCP_REFRESH_MISS. Does it have a cache-control header
>> instead of Expires?
>
> The only headers the web server sends with the HTTP response to Squid
> are "Date", "Server", "Set-cookie", "P3P", "Content-type", "Vary",
> "Content-Encoding", "Content-length", "Connection".
>
>> Are you sure you aren't hitting a previous refresh_pattern line?
>>
>
> Exactly, that's something I don't understand. As per the Squid
> configuration several years ago, the refresh_pattern looked like:
>
> refresh_pattern . 30day_equivalent_minutes 100% 30day_equivalent_minutes
> override-expire
>
> An year ago, the max age was changed to 15 days from 30 and Squid was
> restarted, but still I see the 30day thing coming into effect even
> today. Once the squid.conf is edited, what are the next steps to make
> sure Squid restarts with the newer configuration?
>
>>
>>>> >From squid.conf,
>>>>> refresh_pattern . 21600 100% 21600 override-expire
>>>>>
>>>>> That is, a cached page is fresh if its age in cache < 15 days
>>>>> (21600=15*24*60).
>>>>
>>>> not quite, an object without an explicit expiry time, but that
>>>> can be validated, could be stale in less than 15 days.
>>>>
>>> So, won't all pages with response age < 15 be considered fresh?
>> If an object lacks explicit expiry information and can be validated,
>> it's governed by the percentage and max-age only, and is stale if either
>> is exceeded e.g. a object that was last-modified 5 days ago and
>> validated 3 days ago will have exceeded your 100% limit.
>
> I didn't quite get that. Lets say, a request hits Squid with the URL:
> http://someurl. If thats the first ever request for http://someurl,
> Squid fetches the page from the web server and caches it. The server
> does not send any Cache-control/Expires/Last-Modified-Date headers with
> the response. Squid sends the response to the client and caches the
> content on the disk. 10 days later, another request comes for the same
> url. Note that the page was not validated during the last 10days as
> there were no requests.
>
> Going by the refresh_pattern algorithm with this directive:
> refresh_pattern . 21600 100% 21600 override-expire
>
> - The response is stale if the response age is greater than the
> refresh_pattern max value.
>
> = response age=10, which is less than refresh_pattern max (15); hence
> goto next step
>
> - The response is fresh if the LM-factor is less than the
> refresh_pattern percent value.
>
> = there is no "Last-Modified-Date"; hence skipping this step.
>
> - The response is fresh if the response age is less than the
> refresh_pattern min value.
>
> = 10 < 15, so the cached page is still fresh; end of algorithm
>
> - Otherwise, the response is stale.
>
> Isn't that how its supposed to work?
>

Yes it is.

Add "debug_options 22,3" to your squid.conf and then you get a report
in cache.log of each STALE/FRESH test result and why.
Look for "refreshCheck:" followed by the URL and the staleness test
which matched it.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.15
Received on Thu Dec 31 2009 - 04:58:33 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 31 2009 - 12:00:02 MST