True, the client and the proxying server are tied up intrinsically. I used the wrong wording to name who would benefit. I meant that the server providing the proxied content (the 'other' server; the one not directly talking to the client) could be done and on it's way doing other work while the first two finish their dance.
In this picture: C <--> A <--> P C, the client, makes a request to A which proxies it to P. A & P can do their exchange independant of C & A. If A-P can be done fast, but C-A is slow, then P's wasting resource, no? Ron On Wed, 2005-02-02 at 13:26 -0500, Jeff Trawick wrote: > On Wed, 02 Feb 2005 12:32:39 -0500, Ronald Park <[EMAIL PROTECTED]> wrote: > > I was recently considering a similar patch for mod_proxy along the lines > > of spool_reqbody_cl() method but it would go one step further: spawning > > off a thread to asynchronously read the request into a temp file (or > > files) while the initial thread would continue to stream the io_bufsize > > chunks down the filter chain. > > stray thoughts... > > one thread per proxy request seems pretty heavy weight... perhaps > cool for small number of clients, perhaps a gratuitous use of > resources on a busy server... > > and if threads are shared, then generic event handling apparatus to be > used for other non-proxy code seems more appropriate > > ... > > >This would 'untie' the original client > >and the proxy server in cases where they ran at different speeds (more > >a problem for *large* proxy files where one side or the other could be > >tied up waiting for the slower side for long periods of time... and > >poor Apache caught in the middle). > > the client and proxy server are necessarily tied up until origin > server reads the request and writes the response... why do we care if > they are tied up writing the request out vs. waiting for the response? > it seems like we could burn a lot of resources but get only marginal > response time improvement as payback -- Ronald Park <[EMAIL PROTECTED]>
