[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations...

On Wed, 24 Jun 1998, Chris Wedgwood wrote:

> I was looking into this for sendfile(2), which can have similar constraints
> and requirements.

It occured to me last night that sendfile() may not be the best thing...
my latest scheme for speeding up apache involves what I'm calling "HTTP
flows", and the short story is that the web server has a front-end and a
back-end. The front-end is extremely light, dumb, and single threaded;
the back-end is full featured, and looks almost the same as current
apache. The front-end handles only well-formed HTTP requests and only
requests that fit patterns that the back-end has fed it. In its simplest
form it's a mapping from URL to mmap-region/FD (but it can handle far more
than just these static-only servers). If sendfile() is blocking I can't
use it for this.

I've got a prototype of this method already, and it outperforms threaded
apache by a factor of 50%. It all makes sense when you sit back and
realise the cache benefits from a single thread, not to mention the coding
short-cuts I can take because I can punt any request that isn't
well-formed to the slower, fully functional, backend. The backend is
fully threaded (one thread per request) because it's far easier to let
folks extend the server in a threaded programming model... the backend
wouldn't have any problem with a blocking sendfile(). But the front-end
is where sendfile() would be of the most use... right now it's a typical
poll()/write() implementation.

Food for thought... glad to see someone is thinking about sendfile() :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.237 / U:5.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site