httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject Re: More musings about asynchronous MPMs Re: Event MPM
Date Tue, 23 Nov 2004 17:35:14 GMT
Brian Pane wrote:

> Paul Querna wrote:
>> Paul Querna wrote:
>>  > A thread per-connection that is currently being processed.
>>> Note that this is not the traditional 'event' model that people write 
>>> huge papers about and thttpd raves about, but rather a hybrid that 
>>> uses a Worker Thread todo the processing, and a single 'event' thread 
>>> to handle places where we are waiting for IO. (Currently accept() and 
>>> Keep Alive Requests).  Perhaps it needs a different name? (eworker?)
>>> A future direction to investigate would be to make all of the initial 
>>> Header parsing be done Async, and then switch to a Worker thread to 
>>> preform all the post_read hooks, handlers, and filters.  I believe 
>>> this could be done without breaking many 3rd party modules. (SSL 
>>> could be a bigger challenge here...)
>> Some academics have played with this model of a event thread + worker 
>> threads.  Best I can find is the Java 'SEDA: An Architecture for 
>> Highly Concurrent Server Applications'. [1]
> Yeah, SEDA's model of processing "stages"--basically a succession of 
> thread pools through
> which a request passes, each with a queue in front--looks like a 
> promising way of mixing
> event-based and non-event-based processing.

Thread context switches will suck performance out of any SEDA implementation.

> On a more general topic...and at the risk of igniting a distracting 
> debate...does anybody else
> out there have an interest in doing an async httpd in Java?

Sounds interesting to me though I doubt I would have much time to spend on it.

> There are a lot of reasons *not* to do so, mostly related to all the 
> existing httpd-2.0 modules
> that wouldn't work.  The things that seem appealing about trying a 
> Java-based httpd, though,
> are:
> - The pool memory model at the core of httpd-1.x and -2.x isn't well 
> suited to MPM
> designs where multiple threads need to handle the same 
> connection--possibly at the same
> time, for example when a handler that's generating content needs to push 
> output buckets
> to an I/O completion thread to avoid having to block the (probably 
> heavyweight) handler
> thread or make it event-based.  Garbage collection on a per-object basis 
> would be a lot
> easier.

In general you'll get better performance avoiding async/event driven i/o for i/o that can
be completed quickly 
  . And the httpd pools work perfectly for handling GET requests for smallish static files.
GC per object is 
more difficult to get right imo. That said, I do understand your point; the httpd pool model
falls down in the 
cases where you do need to pass a request to different threads.

> - Modern Java implementations seem to be doing smart things from a 
> scalability perspective,
> like using kqueue/epoll/etc.
They are getting better.

> - And (minor issue) it's a lot easier to refactor things in Java than in 
> C,   and I expect that
> building a good async MPM that handles dynamic content and proxying 
> effectively will
> require a lot of iterations of design trial and error.

For sure.

> Brian

View raw message