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
