On Fri, Dec 22, 2000, Henrik Nordstrom wrote:
> Those boxes were Compaq DS10, 1 Alpha CPU (unknown MHz), 512MB mem,
> RedHat-6.2 derived OS, 3*9GB 10Krpm cache disks making up an effective
> cache space of 20GB, 1*9GB 7.2Krpm system+log disk. Dual UW scsi
> controller. Daily 30 minutes average of 150req/s live traffic during
> peak hours (9-17, corporate environment). Have not been tested with
> polygraph so it is a bit hard to compare figures with other boxes...
Well, I can test it out on a high end GS system with a couple of CPUs,
the trouble is that I *know* with a single CPU I'll still top out at
about 250 request/sec. And that isn't with "real life" network traffic
profiles ..
Which is kind of scary, considering even a couple of years ago, squid
was still capable of doing the same speed on a correctly tuned box. :-)
What people have to realise is that the mechanics behind a poll() loop
really don't scale, and even though it can be made to scale better,
it will take a lot of work. The more CPU you throw at it will make
the code run better, but the main influencing factor behind the behaviour
of poll() is the network traffic patterns, not the CPU you throw at it.
I've kernel-profiled squid boxes spending 50% of their time in a big
poll() loop in the kernel..
[snip]
> And yes, Squid is so far essentially single-CPU oriented. True SMP
> support might appear in Squid-3 which is now only in the very early
> planning stages. Before that we will see Squid-2.5 and possibly even
> Squid-2.6. and before Squid-2.5, 2.4 must get released.. (testers highly
> welcome to test Squid-2.4-HEAD to speed this up)
I'll second that. squid-2.4 has a whole wad of bugfixes and some speedups,
but speedups won't really be visible until at least squid-2.5/2.6 ..
Adrian
-- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Fri Dec 22 2000 - 03:55:30 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:05 MST