Re: Thread implementations...

Michael O'Reilly (michael@metal.iinet.net.au)
26 Jun 1998 14:07:56 +0800


"Amsden, Zachary" <amsdenz@aavid.com> writes:
> Possibly. But according to Squid's own doc, the primary problems
> in Squid performance are
>
> 1) Not enough memory
> 2) Too slow disks
>
> which as far as I can see aren't helped by sendfile. They also
> say "CPU limitations are rarely encountered except in very large
> caches". The same doc describes how to use clusters for large
> caches.

Be careful of blinding applying conclusions without checking the fine
print. In the case of high performance squids I've a fairly
considerable amount of experience.

#1. The web page refers exclusively to squid 1.1.
squid 1.1 has a number of well documented limitations which
basically boil down to squid never being able to effectively
load the machine. By virtue of it single-threading all disk
operations it is impossible to saturate the disk array, the
cpu or the network.

squid 1.2 is a VERY different story. Squid 1.2 will effectively
saturate any hardware you have. In particular, it will make effective
use of disk arrays. This means that for most very large squids, it's
now CPU bound instead of disk bound.

Certainly, the large squids we run are all cpu bound now (40 gig
cache, ~ 80 - 150 transactions per second, PII-266). System CPU time
accounts for 50% of real time CPU.

Michael.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu