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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
