httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <unkn...@riverstyx.net>
Subject Re: select vs. threads vs. fork
Date Tue, 20 Apr 1999 05:07:26 GMT
>From what I've noticed, everyone who's written a select-based server has
been extremely concerned about performance, which may account for that.

---
tani hosokawa
river styx internet


On Mon, 19 Apr 1999 TOKILEY@aol.com wrote:

> In a message dated 99-04-19 18:19:50 EDT, Dean Gaudet writes
> 
> > Both camps have compelling stories on both sides of that argument (you
> >  have to start arguing microarchitectural details about caches, registers,
> >  and how the compiler interacts).  But the threads camp wins the "ease of
> >  implementation" argument in my books.
> >  
> >  Dean
> 
> One element that has been missing from the discussion is simply 
> the extent to which either approach allocates memory ( or not ).
> 
> One fellow asked earlier 'why does the select model always run faster?'.
> 
> One of the big reasons is that most 'select' based servers use a lot
> of static buffers and they don't start 'malloc'ing their brains out when
> a GET request shows up.
> 
> MATHOPD, for example, pre-allocates everything before it drops into 
> the 'select()' loop(s) and this is one of the reasons it runs like lightning.
> 
> malloc() and free() are two of the most expensive calls you can make
> ( and yes... they block at kernel's discretion like open() and read() ).
> 
> If you take ANY server ( select model or multi thread/process ) and you
> cut down on the number of dynamic memory allocations made while 
> servicing a request it's amazing how much faster it gets for that reason 
> alone.
> 
> Is there a good code base out there which is, in fact, multi thread/process
> based but does everything it can to avoid mallocing/freeing its brains out?
> 
> In looking at many different servers... it seems that those who choose
> the multi-thread/process model don't think they have to worry about
> allocating memory all over the place while the select-based servers are always
> very careful about it. 
> 
> My 2 cents worth.
> 
> 


Mime
View raw message