httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: [PATCH] event driven MPM
Date Tue, 08 Jun 2004 19:32:32 GMT
On Tue, 2004-06-08 at 10:23 -0400, Greg Ames wrote:
> Here is the patch - http://apache.org/~gregames/event.patch .  It is currently
> based on the worker MPM from 2.1 HEAD to make it easier to review.  It is
> working well for me under load on Linux and serves pages on Solaris.  When I run 
> specweb99 I've seen around 170 connections served by 5 to 20 worker threads. 
> This is totally dependent on the time the workload spends in keepalive/user 
> think time vs. time spent doing anything else, so YMMV.

Very Neat :D

> This approach could very well hit scalability bottlenecks with various poll() 
> implementations as described on Kegel's web site listed above.  There are many 
> alternatives emerging.  I've gotten a few inquiries about using sys_epoll on 
> Linux, which sounds like a great fit.  I wanted to get something working with 
> plain ol' generic (portable) poll() first before trying out any OS dependent 
> variations.  The current apr_pollset_remove will eventually become a bottleneck 
> too -
> 
> #ifdef HAVE_POLL
>      for (i = 0; i < pollset->nelts; i++) {
> etc

I don't think everyone on this list is aware of this, but I have an
outstanding patch[1] for apr_pollset to add both KQueue and sys_epoll
backends.  Hopefully this will get committed soon.


> Other issues are described at http://apache.org/~gregames/event.laundry_list .
> However I think the patch is robust enough now to post.  I'm very interested in
> feedback and having people try it out before going further.

Mentioned on that laundry list is adding to the pollset from another
thread.  I believe this is supported by both KQueue and sys_epoll.  I
guess it could be easily supported with some #ifdefs.

> From: http://apache.org/~gregames/event.laundry_list
> Should new connections be passed to the event_thread to test for 
> readability? It's good if there are long delays before the first data
> packet is processed; if there is no delay, it's extra complexity and
> wasted cycles.  The thread switches could be minimized if the event
> thread and listener were merged.

I like the general idea, but as a note, FreeBSD has accept filters
which already do some of this. See:
http://www.freebsd.org/cgi/man.cgi?query=accf_http
(It is enabled in the Apache code, but is not commonly enabled in the
FreeBSD kernel.  I don't believe Linux has any equivalent)

I think having the Event Thread also handle the Accept() would be the
best method in the long run.

-Paul Querna

[1] - http://marc.theaimsgroup.com/?t=108650227500001&r=1&w=2


Mime
View raw message