Re: 2nd-biggest Squid performance problem?

 forgot to CC the list...
------- Forwarded message follows -------
From: Andres Kroonmaa <andre@online.ee>
To: Jon Kay <jkay@pushcache.com>
Subject: Re: 2nd-biggest Squid performance problem?
Date sent: Wed, 26 Sep 2001 19:01:23 +0200

On 25 Sep 2001, at 18:37, Jon Kay <jkay@pushcache.com> wrote:

> I have seen alot of discussion on this list of eventio. And it looks
> cool. But I wonder if this is the Right Thing to Work on Right Now.
> I'm not saying it's the wrong thing to work on, I'm just suggesting
> that maybe we don't know whether it is.

 We know. Disk overhead is something you completely can't get rid of.
 FS overhead can somewhat, but already now with some types of FS its
 not that much of an issue anymore (reiserfs).

> Long ago, Duane correctly identified Squid's biggest performance
> problem as filesystem overhead. And now we have the COSS project
> fixing that. That will improve things alot.

 Problem is that we are starting to hit other bottlenecks, especially
 when disk is completely nonissue. For eg. on accelerator with no or
 very small diskspace, network overhead dominates big times.
 Caches with very high memhitrate suck because of that.

> Now that that's going, what is Squid's next Big Performance Problem?
 cpu and latency pigs are:
  1) diskio
  2) networkio
  3) ACLs
 in this order.
 Currently, in addition to networkio itself, poll overhead is damned.

> It would be great if it is event handling, but I must say I have my
> doubts. My impression is that we have been living fat for awhile,
> luxuriating in the - correct - thought that most software overheads
> are dwarfed by the FS overhead.

 Disk performance is hardwired and you can't really overcome it. Disk
 overhead affects performance because cpu is consumed for nothing.
 But when lots of sessions are connected, 10K for eg., then things
 look different, dramatically. disk overhead seems totally nonissue.

> And, whatever that problem turns out to be, is it better to get the
> cycles from that or multiprocessor scaling? Thoughts?

 Whichever provides less overhead under extreme conditions. Ideal
 targets are 1-5K reqs/sec at 10K sessions on generally affordable
 hardware. eventio is prerequisite to even think about it.
 eventio actually helps to think in direction of SMP too.

> Along similar lines, does anybody have results from a profiled Squid
> sitting around? Especially a busy one with thousands of connections
> going?

 http://www.online.ee/~andre/squid/profil/

 http://www.online.ee/~andre/squid/profil/sample-accel.html
  look at 5hour averages here.

 I missed hot hour today, but this accelerator is doing 95% memhits
 and serving about 100-500 req/sec average. On sept.11 it showed
 540 req/sec for 5min avg before melting down... 8K concurrent
 sessions were serviced. Unfortunately I didn't make a snapshot.

------- End of forwarded message -------

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri Sep 28 2001 - 01:36:39 MDT