On Tue, 2008-01-29 at 13:18 +0900, Adrian Chadd wrote: > On Tue, Jan 29, 2008, Amos Jeffries wrote: > > > I had Adrian benchmark 3.x recently. With his specific RAM-pathways test. > > > > The cutoff for speed seems to be Squid3 reaching 500-650 req/sec and > > Squid 2.6 going past that into the 800-900 req/sec ranges. At a few > > hundred concurrent requests. > > http://squidproxy.wordpress.com/ has the graph if anyone is interested. > Thats on a PIII-Celeron 633mhz box with 128KB of L2 cache. > > I've got some munin graphs showing Squid-2.6, Squid-2.7, Squid-2.HEAD and my > hacking branch (s27_adri) which will appear in HEAD as time/funding permits; > I've got s27_adri handling a non-disk workload of ~250 req/sec across a LAN > with about 15% CPU free. Squid-2.6, 2.7 and 3.0 all max out at about 180-200 > req/sec on the same test. > > Unfortunately its a bit tetchy - if the concurrent client count grows above > about 800 clients, the CPU usage spikes to full, concurrent client count > sits at about 3000 and the service time increases to ~1.5 seconds. Squid-2.X > and 3.X do this straight away. Not much can be done about this besides > making the code more efficient (or buying more hardware, but that peaks out > after a certain point too.) > > So if you're running ~100 req/sec, Squid-2.6, 2.7 and 3.0 will be fine for you. ... on a Celeron 633Mhz box! Better hardware supports much higher rates for both Squid2 and Squid3, of course. Eventually, we will have a set of benchmarks to detail that, but for now, I can only say that doing 1000+ req/sec of non-disk traffic is not a problem for Squid2 or Squid3 running on a 3GHz CPU. Squid3 even had time to do ICAP in those tests. YMMV. Squid performance can be significantly improved, of course, and both Squid2 and Squid3 teams are working on that. If you must meet specific performance goals, please contact them. HTH, Alex.
