Re: [SQU] multiprocessor machines

Florin Andrei wrote:

> How does Squid behaves on multiprocessor machines? Is it able to really
> take advantage of multiple CPUs? Does anyone here have experience with
> Squid on multiCPU machines?

Someone posted here just a few days ago with some good observations on
multiprocessor performance. The short answer is that Squid doesn't, in
it's normal configuration take very good advantage of multiple
processors. In an async-i/o compile it can use 100% of the first
processor and ~25% of the second (and each processor thereafter in
decreasing amounts). DiskD probably behaves similarly WRT to MP machines.

To go into a little more detail about what happens on a MP
machine...Squid's primary CPU eater is the select/poll loop that is it's
method of async network I/O. This only happens on one processor,
regardless of use of async or diskd. The disk activity can be shared
pretty equally among several processors because the threads or diskd
processes can operate on different processors, and the OS will be able
to pretty effectively balance them. But when using an async or diskd
compile of Squid, the loads that Squid can maintain becomes a major CPU
factor because of the select/poll loop, and so CPU does become the
bottleneck and there isn't much multiple CPUs can do to help.

 
> Related to this: i understand that Squid doesn't need a lot of CPU
> power. So, just as an example, if i have a monoprocessor MIPS R12000 at
> 300 MHz, how many HTTP requests per second can i serve with Squid
> (assuming a *really fast* I/O system, and lots of memory)? If i will add
> another CPU, will i get doubled performance (assuming that the disk
> subsystem keeps up with the load)?
> Where can i find some Squid benchmarks measured on really fast I/O
> machines, with good 64-bit processors? (i'm especially interested in
> MIPS/SGI, but any other fast I/O architecture will do)

As mentioned above, Squid doesn't use much CPU in it's non-threaded,
single process configuration--but mainly because disk i/o is so slow
that you never go fast enough for it to become a bottleneck. But a
diskd compile uses significantly more CPU, while an async compile uses
even more (but is faster).

A 300MHz box with really fast I/O (you mean 2 or more wide 80 or
Ultra160 SCSI 10k disks, I presume?) and, say, 1GB of RAM with a diskd
compile of Squid (I'll assume you're not running Linux or Solaris, which
are the two properly supported async versions)...you can expect 100-140
reqs/sec. Possibly a little more if you do have 1GB of RAM (if you're
seeing a lot of mem_hits it makes for a nice performance boost).

If I recall correctly, Henrik (Squid hacker, and all around great guy)
formerly maintained a couple of well equipped Alpha+Linux boxen that
sound a bit like what you're thinking of, except with faster processors
and able to use an async i/o compile of Squid. He was seeing about
140-180 reqs/sec at peak load on those boxes, I think.

We build an 800MHz-1GHz Athlon based box with 512MB RAM and dual Ultra
160 10k RPM disks that tops out at about 160-200 reqs/sec sustainable
load (depending on the Polygraph workload in use and which version of
Squid). It's not 64 bit, but it's a mighty fast box, with mighty fast
I/O. I'll probably post some benchmarks at some point, but we're quite
busy right now, as folks are wanting to spend their IT budgets before
the year is up.

Hope this helps.
                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html