httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject Re: PR & 1.1b1
Date Tue, 19 Mar 1996 22:51:31 GMT
On Tue, 19 Mar 1996, Paul Richards wrote:
> overhead in terms of serving a request etc. I assume there's some data
> of some sort on these issues since the consensus seems to be that single-
> threaded servers provide better performance and I'm a bit puzzled as to
> how given that requests will be queued. On the other-hand a single *process*
> server that is multi-threaded would clearly be quicker than a pre-forking
> server such as Apache because of the lower context switching overhead. 

I guess the main reason I brought it up, and the main reasons I have 
gathered from others who want it, is the desire to support something like 
300-400 simultaneous connections without having to have 300-400 full 
blown children around, particularly when you're linking in huge database 
libraries for modules and such.  Pure speed in serving up flat files 
and images is not really too much of an issue, Apache handles that 
currently fine.  Then again, RAM prices are going down.... :)

Rob's model of multiple children multithreaded makes a lot of sense to me 
- it's better for multiprocessor CPU's, it's more robust (we'll never 
squish all NULL dereferencing, if a child dies then the whole server 
doesn't go down), and it'll probably make multithreading-as-an-option-for-
those-OS's-which-support-it-right easier as well.  


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--  |  We're hiring!

View raw message