[squid-users] setting up cache peering

[Alex Samad]

Hi

Thanks I will do when I get back to 3.5. Had to roll back because of
my issues with 3.5 and reverse proxy and outlook.

Are these suggestions still valid with 3.1 ?

Thanks

On 3 December 2015 at 03:22, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> On 2/12/2015 6:50 p.m., Alex Samad wrote:
>> Hi
>>
>> I recently moved to squid-3.5.11-1.el6.x86_64 on centos 6.7.
>>
>> from the centos 3.1 i think ?
>>
>> This what I had originall
>> #cache_peer gsdmz1.xy.com sibling 3128 3130 proxy-only
>> #cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only
>>
>> I had a shared config between the 2 server gsdmz1 and alcdmz1. I would
>> uncomment 1 or the other depending.
>>
>> during my upgrade I coped the gsdmz1 squid config over to alcdmz1 but
>> forgot to uncomment the
>> cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only
>>
>> so alcdmz1 was talking to itself at times.
>>
>> using this as my test
>> wget -d   http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
>> -O /dev/null
>>
>> and setting http_proxy to either alc or gsdmz1 I would get a 504 error.
>>
>>
>> wget -d  http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
>> -O /dev/null
>> Setting --output-document (outputdocument) to /dev/null
>> DEBUG output created by Wget 1.12 on linux-gnu.
>>
>> --2015-12-02 16:35:34--
>> http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
>> Resolving alcdmz1... 10.3.2.111
>> Caching alcdmz1 => 10.3.2.111
>> Connecting to alcdmz1|10.3.2.111|:3128... connected.
>> Created socket 4.
>> Releasing 0x0000000001ea5db0 (new refcount 1).
>>
>> ---request begin---
>> GET http://www.smh.com.au/business/markets-live/markets-live-investors-take-stock-20151201-gld1lu.html
>> HTTP/1.0
>> User-Agent: Wget/1.12 (linux-gnu)
>> Accept: */*
>> Host: www.smh.com.au
>>
>> ---request end---
>> Proxy request sent, awaiting response...
>> ---response begin---
>> HTTP/1.1 504 Gateway Timeout
>> Server: squid
>> Mime-Version: 1.0
>> Date: Wed, 02 Dec 2015 05:35:34 GMT
>> Content-Type: text/html;charset=utf-8
>> Content-Length: 4063
>> X-Squid-Error: ERR_ONLY_IF_CACHED_MISS 0
>> Vary: Accept-Language
>> Content-Language: en
>> X-Cache: MISS from gsdmz1
>> X-Cache-Lookup: MISS from gsdmz1:3128
>> X-Cache: MISS from alcdmz1
>> X-Cache-Lookup: MISS from alcdmz1:3128
>> Via: 1.1 gsdmz1 (squid), 1.1 alcdmz1 (squid)
>> Connection: close
>>
>> ---response end---
>> 504 Gateway Timeout
>> Closed fd 4
>> 2015-12-02 16:35:34 ERROR 504: Gateway Timeout.
>>
>
> *timeout* is terribly bad. Turn the Via header back on. Its sole purpose
> is to let the peers reject messages that are looping like that one.
>
>>
>> I changed the line to be
>> cache_peer gsdmz1.xy.com sibling 3128 3130 proxy-only standby=50
>> on the alcdmz1 box
>> and
>> cache_peer alcdmz1.xy.com sibling 3128 3130 proxy-only standby=50
>> on the gsdmz1 box
>>
>> but this still gave me 504 errors ?
>
> Notice how the difference in configurations is that you added
> standby=50. It should not be having any effect that we know of, but does
> mean that connections are pre-opened to the sibling and thus have a much
> lower latency than any normal TCP connection. If your Squid is searching
> for fastest-route using the netdb latency tables that could be the
> opposite of what you need.
>
>> I tried to force a new version through both proxies by using wget with
>> no-cache option.  But that didn't help.
>
> Sending "no-cache" from the client makes it worse, since that prevents
> HIT from happening on either peer.
>
> When combined with "cache_peer ... proxy-only" configuration it prevents
> any traffic that goes through a peer from being cached.
>
>>
>> So what went wrong, how can I flush out the stale 504.
>
> It is not cached. There is nothing to flush (except perhapse the standby
> connections, see above).
>
>> What is the best way to setup the 2 proxies to talk to each other
>> before going out to the internet.
>
> That depends on the proxies, version, and what you want them to do.
>
>>
>> the proxies run on a pacemaker cluster. I have 2 vip's setup as the
>> proxy addresses, in normal conditions these address are setup 1 on
>> each server. whilst working on a server I can move the vip and not
>> affect any one.
>
> What you have appears to be almost correct. Since you are dealing with
> 3.1 vs 3.5, you need to keep in mind the differences in behaviour
> between HTTP/1.0 (3.1) and HTTP/1.1 (3.5).
>
> One of the side effects is that the default peer query messaging is ICP
> which does not work at all well with HTTP/1.1 Vary caching. HTCP was
> designed to avoid those problems, but needs turning on explcicitly.
>
>>
>>
>> But I would like to take benefit of each others cache, whats the best
>> setup for cache_peer in this setup.
>>
>> Neither server is closer to the internet.
>>
>
>
> I suggest you:
>
> 1) add the "htcp" option to the cache_peer lines. So the peer selection
> can use the full HTTP/1.1 headers to decide if the peer cached object is
> actually usable.
>
> 2) Remove the "via off" from your config file.
>
> 3) remove the standby= parameter from cache_peer until you have at least
> got the original setup working.
>
>
> There might be other things involved, but we cant know that without the
> details about those things existence or absence from your config.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users