httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: project plan
Date Mon, 15 Jul 1996 12:37:36 GMT
Michael Douglass writes:
 > On Fri, 12 Jul 1996, Randy Terbush wrote:
 > 
 > Hmm..  I guess I'm just taking the general conception (gee, didn't we
 > just go through a "general conception" on malloc?) that threads make
 > servers and the like faster.  However, you are probably more than
 > correct in saying that pre-forking helps a great deal...  And when I
 > sit here and just "think" about the issue, the pre-forking does sound
 > like it would be no slower than having threads; and since the
 > pre-forked server handles numerous requests at a time it goes to prove
 > that forking vs. threads would be pretty similar in responsiveness.
 > (And it is responsiveness that counts with a service like this;
 > browsers don't care how long it takes your web server to launch up as
 > long as they don't have to wait.)


Well, threading *may* give quite a substantial performance boost depending
on how threads are implemented since there isn't a full context switch
required to process a different request. I've not looked at rst's thread
implementation yet but there may be no context switch at all for an
user space based implementation.

In practice this may be quite significant. If the server is running on
a dedicated machine then only the server is going to be scheduled most of the
time and if all requests are handled by a single process instantiation then
you avoid all that context switching and things get faster.

For kernel threads you get a performance increase since switching
between threads requires less to be manipulated by the kernel than
switching between processes. This is offset though by more complex 
scheduling algorithms.

Mime
View raw message