RE: Squid performance on the bake-off

> Hello,

Hi Durval et al.

> I've just read the 1st Bake-off report, and I must confess
> I'm somewhat
> surprised that Squid scored so low, less than 25% the rate of
> the second
> worst competitor, the Novell/Dell-S combo.
>
> Comparing the hardware used, specially between Squid and Peregrine
> (which scored a wooping 545% better than Squid, and with much more
> gracious degradation to boot), I see that they are on the same order
> of magnitude for everything but RAM (35% more CPU and disks
> 38% faster,
> compared to 100% more RAM on the Peregrine hardware).

It's dangerous to say x% better; there were a lot of factors in the tests,
and the team took great pains to explain that there were no winners/losers.
Squid had the best price/performance profile for under 100req/sec, and that
was likely one of it's goals for this bake-off.

> Ok, there's the Unix FS handicap to account for, but we are talking
> about _more_than_six_times_ the performance, and in any case
> the tradition
> says that a well-tuned FFS (as is the case with FreeBSD)
> approaches 50%
> of the hardware maximum transfer rate.

It *is* the filesystem -- Perigrine does not run on a FreeBSD filesystem,
but something special that Pei's team has cooked up. I was intrigued to see
that Perigrine wouldn't save the cache between invocations, as they tested
it; this hints at something very specialised.

IMHO a filesystem that is designed for the application, and therefore has
knowledge of how it is used, gives the best performance boost. This
advantage can't be reflected by generic benchmarks (like transfer rate).

From talking to people there, the filesystem really is this big of a deal.
All of the vendors seem to find CPU one of their limitations, except for
squid, whose bottleneck is disk IO.

Cheers,
Received on Sun Apr 11 1999 - 21:19:35 MDT