On 01/07/11 22:34, Gromly Romain wrote:
> 2011/7/1 Amos Jeffries<squid3_at_treenet.co.nz>:
>> On 01/07/11 05:48, Gromly Romain wrote:
>>>
>>> Hello list,
>>>
>>> I'm configuring a squid 2.6 (can't upgrade) as reverse proxy and i've
>>> some questions about how cache works.
>>>
>>
>> Please see http://www.mnot.net/cache_docs/ it has a lot of enlightening
>> descriptions.
>
> Thanks for this url in french (is my english so bad? :p), very instructive!
>
?huh shows up English to me. "This is an informational document.
Although technical in nature, ..."
>>> Here, how my architecture works:
>>>
>>> AV Client> GET /file.zip (HTTP/1.1 with Cache-Control: max-age=0 and
>>> sometimes, with also If-Modified-Since: date, it depends of the file)
>>> => Squid configured with refresh_pattern -i \.zip$ 1440 100% 1440 =>
>>> Apache server with file.zip hosted with a classic configuration
>>>
>>> If I try to get the file.zip with IE, it seems to work, I first have a
>>> TCP_MISS/200 and then TCP_HIT/200. No request to the Apache server.
>>>
>>> If I try to get the file.zip with the AV Client, I first have a
>>> TCP_MISS/200 but then, I always have a TCP_REFRESH_HIT/200, so Squid
>>> ask to the Apache server if the file is modified, Apache says 304.
>>>
>>> I don't want to have this 304 all the time on my Apache but only when
>>> the file is older than 1 day.
>>
>> AV client is sending "max-age=0" otherwise known as "revalidate immediately"
>> or "don't send me anything you are in the slightest bit unsure about".
>>
>> refresh_pattern "ignore-reload" is the closest 2.x series has to ignoring
>> that.
>>
>> refresh_pattern "reload_into_ims" will covert max-age=0 requests into IMS
>> which allow the Apache to respond with the small 304 to instead of a full
>> 2xx and copy of the object.
>
> I tried with ignore-reload but still have 304 relayed to Apache...
>
>>>
>>> I think it could come from the cache-control: max-age=0 and I've tried
>>> all different refresh_pattern configuration, particulary with
>>> override-expires but I still have this TCP_REFRESH_HIT
>>>
>>> Also, all my 404 ou 403 are relayed to the Apache, even if I've put
>>> negative_ttl to 15 minutes...
>>
>> negative_ttl is a DoS on the clients. If one of them gets a temporary
>> failure. They all see it for the duration of the TTL.
>>
>> This is the digital equivalent of unplugging the whole box whenever the
>> network card starts to get a little overloaded. Instead of just dropping the
>> odd packet.
>>
>>>
>>> So to resume for all that don't want to read: how not to have
>>> TCP_REFRESH_HIT all the time and how not to relay 404 or 403 error to
>>> the Apache?
>>
>> I was about to say: Apache needs to send Date: and Cache-Control: headers
>> on the 4xx messages it emits. Squid should cache them same as for 2xx
>> results.
>>
>> But sadly you say you are stuck using 2.6. That version does not cache a lot
>> of things which later versions are fixed to cache. Those headers may help,
>> but then again it may not.
>>
>>
>> Is there any particular reason you are stuck with 2.6? I'm not awarae of any
>> technical reasons why you can't move to 2.7 series at least.
>
> Our customer doesn't want to have different version of squid in his
> network and because they can't upgrade 1500 servers as quick as we
> need, we have to stay in 2.6.
>
> Meanwhile, I've tried in my test environnement Squid 3.1 and I've same
> issue even with ignore-reload actived, and 4xx are relayed to
> Apache...
>
> Now (with 3.1), I have TCP_HIT/200 or TCP_MEM_HIT/200 for some files
> and TCP_MISS/304 for some others on Squid because Apache says 304 to
> requests...
MISS/304 is the client attempting to validate a cached version somewhere
outside your network. Which is also not currently in your local gateway
Squid. Net bandwidth saving equal to the size of the object which might
have been sent but was not. CPU consumption savings are uncertain, worst
case is zero CPU saving.
Amos
-- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.13 Beta testers wanted for 3.2.0.9Received on Sun Jul 03 2011 - 01:47:21 MDT
This archive was generated by hypermail 2.2.0 : Mon Jul 04 2011 - 12:00:02 MDT