Basically, yes. 1-2 and possibly 3 CPUs, the current squid uses
resources
reasonably (with things like diskd enabled, so there are multiple
processes
at least). On 4+ CPUs, it wastes a lot of CPU, since it's not designed
to
use multiple CPUs.
David.
-- David Luyer Phone: +61 3 9674 7525 Network Development Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF > -----Original Message----- > From: maer727@sohu.com [mailto:maer727@sohu.com] > Sent: Friday, 26 April 2002 4:46 PM > To: david@luyer.net > Cc: squid-dev@squid-cache.org > Subject: №íⅴ:Re: What to know detail about why Squid use > single process. > > > Thanks, David pal! > > You mentioned, > > ///////////////////////////////////////////////////////////////////// > On less than that, diskd, the kernel, etc should be efficiently using > the resources already. > ///////////////////////////////////////////////////////////////////// > > Do you mean that if the condition is less than 4 CPUs, it is better > to use current design of Squid. Maybe Squid 2.5 or Squid 2.4. Am I > correct? > > Best regards, > George Ma > > ----- 戢冼 ----- > From: David Luyer > To: squid-dev@squid-cache.org > Subject: Re: What to know detail about why Squid use single process. > Sent: Wed Apr 24 23:48:20 CST 2002 > > > Has anyone investigated extending the squid model to use > > multiple threads, without a complete redesign? > > > > One approach which occurred to me was to have some kind of > > "eventAddImmediate", and have commselect/commpoll call that > > when they find an fd is ready, and then have some 'worker > > threads' which pick up pending events. Basically one 'master' > > thread and a number of 'worker' threads. > > > > It would mean making some parts of the code more thread-safe, > > however on a 4+ CPU machine I'd expect a speedup. On less > > than that, diskd, the kernel, etc should be efficiently using > > the resources already. > > > > David. > > > >Received on Fri Apr 26 2002 - 02:21:24 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:20 MST