httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Robinson <>
Subject Re: project plan
Date Sun, 14 Jul 1996 17:41:11 GMT
On Fri, 12 Jul 1996, Michael Douglass wrote:

> On Fri, 12 Jul 1996, Randy Terbush wrote:
> > Hmmm. I was think that I remember you (Alexei) posting some *simple*
> > benchmarks of an early apache-XX that was no faster than the current
> > code. Since we're pre-forking, forking really isn't much of an issue
> > except during significant increases in demand on the server pool.
> 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.)
> Having thought that, what would the benefit of a threaded server be?
> (Other than to say that apache is multithreaded...)

1. In terms of response time, Apache is not significantly slower than any 
   single-process server that I have seen.

2. Rst's server is NOT MULTI-THREADED. I think it would be a big mistake
   on the part of the group to suggest to the world that it was.
   The best description is 'single process', 'single process/single thread'
   or, (if you must) 'multiple user-level threaded'. 'Multi-threaded' means
   multiple kernel threads in a single process, at least, that's what it
   means to the vast majority of programmers.

3. A single process (whether single- or multi-threaded) server is not 
   signifcantly faster than a pre-forking server. There is, however,
   some advantage in reduced context-switch rates (for very highly loaded
   servers). The reduced memory usage is almost never significant.

4. A single process/single-threaded server will be signficantly slower
   on multiple-CPU machines, which are actually rather common. Of course,
   this need not be a problem if you change it to a small-n group of
   processes each handling several requests.

5. A single process/single-threaded model can be much slower if it ever
   blocks in a system call. Whether this happens depends on the cleverness
   of the programmer, (and the unluckiness). For some sites, this is
   a big loose. For example, cambridge astronomy's web server NFS mounts
   some web pages from disks around the site. (Pages with low hit rates.)
   It would be unfortunate for the whole web server to stop because
   it is blocked in an open() for a page that is read once per hour.

So what _are_ the advantages of a multi-threaded (user or kernel) server?
As has been pointed out, HTTP-NG servers would be easier to code using
threads. There are several ways to achieve this.

1. Use kernel threads.

Advantages: The natural way of solving the problem. Very robust, efficient.
The future-proof solution. A POSIX threads standard exists, so porting
between MT platforms should not be hard. An MT Apache probably already 

Disadvantages: Threads are not available on legacy systems. Although not
dominant on the web, they are dominant in this group. 8-)

2. Use multiple, communicating processes.

Advantages: Could be made portable and robust.

Disadvantages: Harder to code. A pain supporting three communication methods
(mmap, shmem and pipes). Less efficient.  Outdated coding. No prototype 
exists. (Though some experience through the scoreboard mechanism.)

3. Use a single process with user-level threads.

Advantages: Efficient. Not too hard to port. A prototype exists.

Disadvantages: Less robust. Some systems may be difficult to port. Outdated
coding. Not ideal for multiple-CPU hardware.

I think that the best stratagy is to design a multi-threaded server, but
with fallback support for clunky Unixes via one of the other approaches.


View raw message