From new-httpd-return-3223-apmail-new-httpd-archive=apache.org@apache.org Tue May 02 16:22:24 2000 Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 30467 invoked by uid 500); 2 May 2000 16:22:20 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 30455 invoked from network); 2 May 2000 16:22:17 -0000 Date: Tue, 2 May 2000 09:22:17 -0700 (PDT) From: dean gaudet To: new-httpd@apache.org Subject: Re: Maintenance of mod_proxy and async i/o In-Reply-To: <20000425055540.A4873@www.easysolutions.net> Message-ID: X-comment: visit http://arctic.org/~dean/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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. >