Re: 2nd-biggest Squid performance problem?

On Tue, Sep 25, 2001, Jon Kay wrote:
> I have seen alot of discussion on this list of eventio. And it looks
> cool. But I wonder if this is the Right Thing to Work on Right Now.
> I'm not saying it's the wrong thing to work on, I'm just suggesting
> that maybe we don't know whether it is.
>
> Long ago, Duane correctly identified Squid's biggest performance
> problem as filesystem overhead. And now we have the COSS project
> fixing that. That will improve things alot.
>
> Now that that's going, what is Squid's next Big Performance Problem?
> It would be great if it is event handling, but I must say I have my
> doubts. My impression is that we have been living fat for awhile,
> luxuriating in the - correct - thought that most software overheads
> are dwarfed by the FS overhead.
>
> And, whatever that problem turns out to be, is it better to get the
> cycles from that or multiprocessor scaling? Thoughts?

Ok. After spending the last two years going down a very, very large
number of paths, I think I've gotten the idea as to why squid is
inefficient.

Yup, the inefficient FS is one problem, and even the current beta
COSS code performs remarkably well, but even with COSS squid flattens
out far, far under the commercial caches, even when you scale them
down to a single CPU.

However, every time I start "optimising" something in squid I hit
a wall at the client/server side. The storage manager is relatively
easy to change, but there's some assumptions on the way it works
that throws things off.

As for multiprocessor scaling - once squid is optimised and doesn't
keep a 'memory cache' of objects, multiprocessor scaling can happen
rather easily. :)

Right now its all up to time - I'm sure Duane, Henrik and Robert are
busy as hell and I'm busy trying to find work back home in Perth.

Adrian
Received on Wed Sep 26 2001 - 19:32:38 MDT