I would recommend upgrading the Squid cluster because
it's run on a
very significantly old version of the software, lacks several years
worth of general patches and maintenance, and because it's not THAT
big a deal. As I mentioned earlier in thread, I spent several years
running Squid (at the time, 3.0-stablevarious and 3.1 beta tests) at a
large site, and it didn't take that much time and effort despite
working actively with Amos and others on what turned out to be an
uninitialized buffer problem for over a year and having to compile,
tune, and seriously test all the versions from 3.0-STABLE3 through ...
19, it looks like. It was perhaps 20% of my total work for about 3
years, and would have been far less had it not been for the one
persistent bug (going from the prior 2.6 squids to 3.0 took about 3
months of me 1/4 time-ish). Performance was noticeably better with
3.0 vs 2.6 and 2.7.
Well, by all means, add our patches in to the newer version, and
provide a source package.
Avoidance of obsolete version software rot is a key
operations
technique. My current main commercial consulting customer has 5
years-past-end-of-support key enterprise infrastructure software that
they don't even quite know how to upgrade, it's so old now. Don't let
your versions get that old...
Yes, 2.7 is still getting necessary Squid project patches, latest to
STABLE9 in March 2010, but still. It's old 8-)
Our plan is to eventually move away from squid and to varnish.
Upgrading squid really isn't amazingly high on our priority list right
now.
Respectfully,
Ryan Lane