Re: squid-smp

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 15 Oct 2009 22:27:46 +1300

Adrian Chadd wrote:
> 2009/10/15 Sachin Malave <sachinmalave_at_gmail.com>:
>
>> Its not like we want to make project bad. Squid was not deployed on
>> smp before because we did not have shared memory architectures
>> (multi-cores), also the library support for multi-threading was like
>> nightmare for people. Now things are changed, it is very easy to
>> manage threads, people have multi-core machines at their desktops, and
>> as hardware is available now or later somebody has to try and build
>> SMP support. think about future.......
>>
>> To cop with internet speed & increase in number of users, Squid must
>> use multi-core architecture and distribute its work............
>
> I 100% agree with your comments. I agree 100% that Squid needs to be
> made scalable on multi-core boxes.
>
> Writing threaded code may be easier now than in the past, but the ways
> of screwing stability, debuggability, performance and such -haven't-
> changed.. This is what I'm trying to get across. :)

Aye, understood. Which is why I've made sure all this discussion is done
in squid-dev. So those like yourself who might have anything to point at
as good/bad examples can do so.

Sure, Squid can be re-written from the group up yet again. But none of
us want the ten year delay that will cause. The answer is to drop eight
years of improvements and use the Squid-2 code, or go ahead with a
somewhat incompletely upgraded Squid-3 code. Leveraging some of the SMP
work to further upgrade the remaining sections, while just slipping SMP
into the currently upgraded components.

Do you actually have any relevant implementations you in your infinite
wisdom and foresight want to point us at? Or just diss us for not
knowing enough?

I'm already aware of the overall models Varnish, Oops, Apache, and
Polipo, and Nginx are documented as using. Without looking at the code
it's clear that their approaches are not beneficial to Squid without
major re-plumbing.

The solution we have to use is a mix, possibly unique to Squid, which
retains Squids features and niche coverage. The right mix of tools for
each task to be performed: child processes, IPC, and events. Now adding
threads for the pieces that are applicable. There is order in the chaos.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE19
   Current Beta Squid 3.1.0.14
Received on Thu Oct 15 2009 - 09:27:52 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 15 2009 - 12:00:05 MDT