httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Park <>
Subject Re: re-do of proxy request body handling - ready for review
Date Wed, 02 Feb 2005 18:46:47 GMT
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?


On Wed, 2005-02-02 at 13:26 -0500, Jeff Trawick wrote:
> On Wed, 02 Feb 2005 12:32:39 -0500, Ronald Park <> 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 <>

View raw message