httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 19:46:00 GMT
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