Since Apache 2.0, we've had the MPM architecture, which means you can
plug in your choice of processing model. That's also how Apache 2
works cross-platform, rather than being (like Apache 1) a Unix server
ported with lots of compromises in performance/etc to other platforms.
i was surprised that event based MPM did not catch too much attention
of Apache developers? maybe i am wrong? :)
Howard,
Well, your both right and wrong :-) The event driven network i/o model
is really powerful and as you say, it can be much more robust as
compared to a threaded process model, and it's also very scalable (think
large number of concurrent clients). Here are what I see as the two
basic problems:
1. Apache httpd runs everywhere or nearly so. Most platforms have their
own event driven network i/o APIs (epoll, KQueue, aio, and so forth).
Some platforms (notably Windows) have async network i/o APIs which means
you also have to allocate and manage i/o buffers across your network i/o
calls. We've never quite settled on the right abstraction layer that is
both portable, performs well and accommodates platforms that have more
traditional network i/o models.
2. The core Apache httpd architecture is not really suited for use with
an event driven/async network i/o API. Yes we made the event MPM work ,
but it feels kinda hackish to me (and I helped do the work so I gotta
right to criticize :-). Someone recently suggested making the core
httpd engine a state server; i really like that idea and maybe it will
be a feature of 'amsterdam'. We'll see.
Bill
