Date: Tue, 09 May 95 17:01:38 -0700 From: Bakul Shah <bakul@netcom.com> To: terry@cs.weber.edu (Terry Lambert) Cc: taob@gate.sinica.edu.tw (Brian Tao), nc@ai.net, Arjan.deVet@nl.cis.philips.com, freebsd-hackers@FreeBSD.org, Guido.VanRooij@nl.cis.philips.com Subject: Re: Apache + FreeBSD 2.0 benchmark results (fwd) Message-ID: <199505100001.RAA29299@netcom14.netcom.com> In-Reply-To: Your message of "Tue, 09 May 95 15:28:07 MDT." <9505092128.AA19726@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The correct term for "pre-forking" is "spawn-ahead". ... > > I was always under the impression that the creation of another > > process is called "forking" under UNIX and not "spawning (isn't that > > VAX-speak?). > Nope; just generic CS-speak. `spawning' is approx. equal to fork + exec, not just fork. A system that provided spawn can do certain optimizations (with a loss of some flexibility). I have never heard of pre-spawning. Are you trying to, er.., spawn new words? > > What, have a specially-compiled kernel that can fork off httpd's > > in no time at all? FYI, this has been used in atleast one system. The kernel kept a number of server processes. Under heavy load more processes were forked off, under light load extra idle processes were killed off. A variation of `select' to do this may be something worth investigaing. Typically a server process does a select to wait for a request to arrive. If you want to provide more threads of control dynamically, and these threads agree to cooperate, you would use this hypothetical `server-select'. Once some parameters are set, the kernel would dynamically add or remove threads depending on traffic (but only in serever-select). > If you don't convert the I/O requests, then you aren't really a > multithreaded server at all, since a blocking request in any thread > of control can block other threads of control that would otherwise > be runnable. Correct. Select() in this context is suitable for servicing lots of `short term' requests, not long lasting ones. So long requests should handed to another thread. But doing so in Unix eats up more time. > The other alternative is a Non-Blocking I/O Dispatch model, where you > guarantee that you will not attempt potentially blocking operations > in the context of a dispatched thread of control. ... > ... Depending on what you do with > this model, you can actually end up with some very complex finite > state automatons to get the desired behaviour. Right. I think `asynchronous' IO probably provides the best performance with a moderate increase in complexity. Alas, we can't do that under Unix:-( Any thoughts on a decent implementation of that? --bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505100001.RAA29299>