httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Maintenance of mod_proxy and async i/o
Date Tue, 25 Apr 2000 05:55:40 GMT

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

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 :->)

Shane Nay.

View raw message