httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Park <r...@cnet.com>
Subject Re: Multi-threaded proxy? was Re: re-do of proxy request body handling - ready for review
Date Wed, 02 Feb 2005 17:49:57 GMT
Hmm, don't know enough about Event MPM to comment on that part of the
message, but with regards to the performance for small requests, in my
original 'design' for this, I figured it would do one synchronous read
first, pass that through the filter chain and, if '(!seen_eos)', then
it would pay the cost to set up the asynchronous details.  Hopefully
then most sites could alleviate performance issues by fiddling with
the ProxyIOBufferSize directive to fit all requests within this value
while large requests would be many multiples of this size.

Ron

On Wed, 2005-02-02 at 09:37 -0800, Paul Querna wrote:
> 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. 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).
> > 
> 
> One thought I have been tossing around for a long time is tying the 
> proxy code into the Event MPM.  Instead of a thread blocking while it 
> waits for a backend reply, the backend server's FD would be added to the 
> Event Thread, and then when the reply is ready, any available worker 
> thread would handle it, like they do new requests.
> 
> This would work well for backend servers that might take a second or two 
>   for a reply, but it does add at least 3 context switches.  (in some 
> use cases this would work great, in others, it would hurt performance...)
> 
> -Paul
-- 
Ronald Park <ronp@cnet.com>


Mime
View raw message