httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [Fwd: Pthread library benchmarks]
Date Tue, 15 Dec 1998 17:40:25 GMT
On Tue, 15 Dec 1998, Scott Dybiec wrote:

> Dean Gaudet wrote:
> 
> > On Sun, 13 Dec 1998, Scott Dybiec wrote:
> >
> > > You may want to take the high cost of creating and context switching
> > > with LinuxThreads into consideration when building the threaded version
> > > of Apache for Linux. PMPthreads is the user-based pthread library used
> > > for comparison.
> >
> > The linuxthreads creation cost is high because of lacking functionality in
> > clone() which essentially requires a context switch into a "master" thread
> > to create a new thread.  There's a few proposals to fix this.
> 
> Good to hear that fixes are in process. Where are discussions about this
> taking place?

on linux-kernel... check the archives for the past 8 or 9 months you
should find something.

> Looking at the benchmarks I took, it seemed to me that if heavy cost of
> thread creation (and maybe context switching) with LinuxThreads were not
> considered in the design of the threaded version of Apache, performance would
> suffer. The cost of thread creation with LinuxThreads is roughly about one
> third (1/3) that of creating a process, whereas with a more typical library,
> like PMPthreads, is (according to my calculations) about one eighty-seventh
> (1/87) that of creating a process.

I suspect that this isn't just a linux phenomenon.  The general problem
is:  accept() a connection from a socket, and dispatch into a thread.  The
"best" way to do this depends on a dozen or so factors.  For example here
are some options:

- maintain a thread pool, a single thread sits in accept() and dispatches
to one of the threads in the pool
- maintain a thread pool, a single thread from the pool sits in accept()
and leaves the pool when a connection is received, awakening another
thread on the way out
- maintain multiple independant thread pools, multiple threads sit in
accept(), use either of the above two variations
- a single thread sits in accept() and spawns new threads as connections
arrive
- multiple threads sit in accept() and spawn new threads as connections
arrive
... and yet more variations

Some factors which influence which of these is cheapest include:
- is the thread package userland, kernel, or hybrid?
- are there multiple CPUs in the system?
- when thread A release a mutex and thread B is given access to the mutex,
does the thread package context switch to B immediately or does A get
to finish its timeslice?
- does the thread package provide a mechanism for LIFO (rather than
the standard/required FIFO) on a mutex?
- ... ?

I personally believe that maintaining thread pools at the application
layer is quite distasteful -- the thread package should do that.  In fact,
the thread package should provide the above as a primitive otherwise the
application developper needs to figure out just which method is the most
streamlined for the particular package.

I suspect we'll abstract this away and tuck it into our portability
library.

> Yes, the library could be switched to PMPthreads, but
> 
> 1. Supporting two libraries might be cumbersome.

No moreso than supporting another operating system.

> 2. Only LinuxThreads supports SMP, so supporting it is probably critical.

Like I said already, they're both pthreads implementations.  If we
support pthreads then we support both.

> Is Apache really moving to a thread-based server? If so, why?

Read the perf-tuning document.  Visit dev.apache.org.  Peruse the
apache-2.0 cvs repository.  Read the various research papers that compare
process model servers to thread model servers.  Did I mention the
perf-tuning document yet? 

Dean


Mime
View raw message