Re: Maintenance of mod_proxy and async i/o

[dean gaudet <dg...@arctic.org>]

i like the idea -- and it was part of what i wanted to happen in
apache-2.1.  although i would tend to use the same thread for pushing bits
and accepting new connections... doesn't seem necessary to have two
threads going into select/poll.  but benchmarking would show which method
works best.

i did some of the groundwork for you already by making the 2.0 BUFF handle
non-blocking sockets.  (which assumes the caller of BUFF is looping around
calling bwrite... doesn't work for folks doing bputc, bputs... which is OK
in my books, 'cause bputc/bputs folks want a thread to do their dynamic
logic anyhow.)

if you search around last year when i released the first MPM stuff you'll
see a bunch of stuff in the archive about async MPMs.  check may/june
1999.

-dean

On Tue, 25 Apr 2000 shane@isupportlive.com wrote:

> new-httpders,
> 
> Well... I spent yesterday hacking away at mod_proxy, and spent this
> morning reading through the mod_proxy discussion of last week.  Anyhow
> it seems like a lot of people are posting patches for mod_proxy
> (Graham & Sam especially) and we probably need to put together some
> for of maintanence crew for this.  There are a lot of open items that
> need going through, and some interesting ideas put forth by Dean
> Gaudet that could be nice. (Hi dean :->)  Maybe a mailing list of
> folks that are interested in hacking away at it.  Anyhow... on to my
> idea:
> 
> I worked with Zach Brown on phhttpd, and it uses a really cool async
> i/o model for pushing bits that's really fast.  It would be nice to
> incorporate this functionality into mod_proxy.  However the code
> really needs to be cleaned up in the same light.., anyway.  What I'm
> thinking is if we split off a thread/process from the main pre-forked
> apache threads that's only job is to push bits to the client from the
> cache, or pre-fetched response data by the main apache children that
> would be really cool and lightweight.  It would also allow the main
> children to leverage modules such as mod_ssl, etc. and would clean up
> our "sending out" code.
> 
> So basically we'd be talking about during module init it pushes out a
> process/thread that will handle all outgoing communication for
> mod_proxy.  (very lightweight child I should note)  The apache children
> would be responsible for collecting the outgoing data, and formating
> it for that other child.  Then they would pass the fd, and the
> reference to where the pre-fetched data could be found.  Then
> mod_proxy's lightweight thread/process would use a sigio interface (or
> something "different" on platforms that don't support this, select?) to
> actually push bits to the 28.8k clients, or however fast.  This has
> been proven to be a very successful model in terms of speed with
> phhttpd and wouldn't leave the apache children sitting around feeding
> a slow client a 6MB file.
> 
> Anyway, that's my idea... I'd like to implement it unless anyone has
> any specific objections.  We really need to get a maintainer for this
> module or a group of folks that are working in concert.  (This seems
> to already be happening to some degree... I'm a little concerned about
> the 2.0 turnover, and how this affects what I'm thinking of... I guess
> that's Sam's department :->)
> 
> Thanks,
> Shane Nay.
>