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
