On 2/07/2012 8:08 p.m., Mr J Potter wrote:
Hi all,
Does anyone have any tips on how to fix this issue:
We've just moved to squid3 from squid2, and now when we do squid3 -k
reconfigure we get about 30 seconds of squid refusing/failing to
forward requests while it rejigs itself. I don't know if this is
squid3 rescanning the cache or doing something with squidguard (we
have a fairly complex+large squidguard setup)? I don't think this
happened with squid2.
What can we do to make this less noticeable?
- make it reconfigure faster?
Always good, regardless of the version. Also making it reconfigure less
often. You really only should not need to reconfigure much.
- multiple squid servers - can we do failover somehow (either proxy
DNS record points to them both, or they automatically redirect (is
this what cache peers are for?))?
Yes cache_peer are for this sort of thing *within* a cluster. For
client-facing failover PAC file or DNS is appropriate depending on
whether you are serving as forward or reverse proxy respectively.
- go back to squid 2 - I didn't see any end user benefits of squid3
over squid2...
any help would be greatly appreciated.
Which particular Squid versions? that matters a lot with questions like
these. The other option is to upgrade to a current release if your 3.x
version is old. We have resolved a number of speed and resource usage
problems already (but as always there are more to go though).
NP: 2.x and 3.x version numbers between 2.5 and 3.2 are parallel
branches with tradeoffs in both directions. Unfortunately speed was
traded away for features in the 3.x side of the 3.0/3.1 pair. Squid-3.2
will supercede both branches and hopefully resolve the whole decision mess.
Amos
