Whats going on with Squid-2 and Squid-3 ?
By Adrian Chadd
A few people have asked me what the deal is with Squid-2 and Squid-3.
“Why are you developing on Squid-2 when Squid-3 is now out?”
“Should I upgrade to Squid-3 now that its released?”
I’m focusing on Squid-2 for a few reasons, namely:
*
Its what people running high-traffic sites are currently running, and Squid-3 doesn’t work at all for them;
*
I was fed up waiting for Squid-3 to be released and for it to become mature enough for users to migrate to before I started my performance work. I gave up about 12 months ago and began planning out the work thats currently going on.
*
I’m personally much more familiar with the Squid-2 codebase than the Squid-3 codebase.
So what exactly am I doing to Squid-2? Well, I’m doing all the things to Squid-2 which I personally believe we should’ve done in the C++ Squid-3 branch before all the “new stuff” was added. You can find it all at
squid/s27_adri changes . A summary of what I’m doing in this first round:
*
I’m taking a very sharp scalpel to the codebase and removing all of the extra data copies and buffering which is going on;
*
I’m reworking the buffer management so arbitrary sized data buffers can be used, rather than fixed 4k buffers for network/disk traffic;
*
I’m reworking the Strings interface to use reference counting and reference underlying buffers, saving on memcpy() and malloc() calls, cutting down on the amount of transient memory used to handle requests and dropping the CPU and memory bus utilisation quite dramatically;
*
I’m reworking the dataflow between server->store and store->client to use the above reference counted buffers, so data isn’t memcpy()’ed between layers, again dropping CPU and memory bus utilisation;
*
And I’m going to break out as much of the code into external libraries with well-understood dependencies, as preparation for documentation, unit testing and further profiling.
My aim is to fix whatever bugs show up in Squid-2.7 and then in Squid-2.HEAD (which has some of the above included already.) I’ll then start bringing across my changes as they’ve been tested and been found stable. My aim is to have the bulk of the above done within the next month or so and get it into Squid-2.HEAD and concentrate on making it stable before I continue tidying up the dataflow and restructuring the ugly bits of code.
Whats this mean for Squid-3? The Squid-3 guys are doing some great work with things such as ICAP and IPv6 and I hope that they’ll gain more experience with their codebase over the next 12 months or so. I’m certainly not bringing ICAP support into Squid-2 until I’ve reworked the dataflow and tidied up the code enough for ICAP to sit comfortably in the data pipeline, rather than have it bolted onto the side and hooking into strange places where it shouldn’t. (I may bring in IPv6 into Squid-2 soon though!)
Hopefully my work and their work will culminate with the development of the next Squid major version over the next 12 to 24 months. There’s a long way to go though and my main aim here is to get faster, better and shinier code out to the majority of Squid users now so they can benefit from the development, rather than repeating the 4-odd year gap between Squid-2.5 and Squid-2.6. Users hated that.
So whats it mean for you?
*
If you want to try out Squid-3; if you want supported ICAP services then try it out.
*
Squid-2.X will continue being developed over the next 12 months as time permits, so don’t feel like you have to move to Squid-3.
*
If you feel adventurous, try out Squid-2.7. Initial reports are that its stable and slightly less CPU intensive.
*
Squid-2.7 is the first version to include changes to allow Youtube and Microsoft Updates caching. It doesn’t do it out of the box, but the support is there, and I’ll be publishing test rules soon to let people start caching this stuff.
*
If you feel really adventurous then try out Squid-2.HEAD and report back if you have any issues. It should be even less CPU intensive, but only under certain workloads.