httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: new acceptor logic.
Date Mon, 22 Feb 1999 19:34:42 GMT

This is also a performance hit.  What you are suggesting, is a pool of
threads where each thread does an accept, and then serves the request.
When it leaves the accept, another thread does the accept, and when the
inital thread finishes serving the request, it goes back to blocking on
the mutex.  Basically, the hit comes in that for every request, we are
waking up a thread, and then having the thread sleep.  Our performance
people have found that having threads wake up and go to sleep is one of
the places that most of the time is wasted.

Even if the thread trys to acquire the mutex before going to sleep, there
is a very small window during which it will be the one to acquire the
mutex, so it is most likely to go to sleep for at least some period of
time.  With multiple process and multiple threads all grabbing for that
mutex, the chance that the original thread sleeps increases, because there
is less of a chance the mutex will be available.

With the single acceptor thread per socket, we have X threads always
accepting data, and then we push that data onto a queue.  A thread wakes
up and grabs the data.  If when it comes back after serving the request,
there is data on the queue again, it doesn't sleep at all.  Instead, the
original thread grabs the data off the queue, and serves the request.

That is our current thinking, is that we want to optimize our performance,
and reduce the number of times we have to have threads sleeping.

Ryan



On Mon, 22 Feb 1999, Dean Gaudet wrote:

> 
> 
> On Mon, 22 Feb 1999, Manoj Kasichainula wrote:
> 
> > > Or pay one worker per socket -- let multiple be in accept, just on
> > > different sockets.  If folks have less than busy sockets they'll be paying
> > > one less than busy thread... but little extra cpu otherwise.
> > 
> > If I understand this, we have to have a mechanism to make sure that
> > worker threads accept() on the busiest sockets. We've thought about
> > it, since it's what the mainframe web server developers are working
> > with, but we haven't come up with a bulletproof way of doing this on
> > Unix yet. Thoughts?
> 
> No, you need M+N threads where M is the number of sockets, and N is the
> number of threads you want to have in flight servicing requests.  KISS ... 
> don't do anything special for the busy sockets -- just keep a FIFO list of
> sockets that don't have anything accepting on them.
> 
> It's not too hard -- for a single socket you need one lock, acquire it
> when going into accept().  For multiple sockets you need a FIFO of sockets
> ready for accept, with a lock for that FIFO... although on first
> inspection it seems you need to acquire the FIFO twice per accept, which
> sucks... there's probably a trick you can play depending on which of the
> various pthread locking primitives are available. 
> 
> Dean
> 
> 
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message