On Tue, 19 Feb 2002, Graham Leggett wrote:

> Igor Sysoev wrote:
> > The main problem with mod_proxy is that it reads backend response
> > to 8K buffer and than sends it to client. When it have sent it
> > to client it reads again from backend. After it have sent whole
> > content to client it flushes buffer and only after this it closes
> > backend socket. Even backend send all to its kernel buffer and
> > response is recevied in frontend kernel buffer nevertheless backend
> > need to wait frontend in lingering_close. So we lose at least 2 seconds
> > with small client and big response.
> Will making the 8k buffer bigger solve this problem?

No. It does not resolve 2-second lingering close on backend.

> I will check that once the end of a request has been detected from the
> backend, this backend connection is closed before attempting to send the
> last chunk to the frontend. This should have the effect that with a
> large enough buffer, the backend will not have to wait around while a
> slow frontend munches the bytes.

1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend.
But ap_proxy_send_fb() flushes output to client so it can hang
for a long time.

> > > Once mod_cache is finished in v2.0, (in theory) the capability will be
> > > there to disengage expensive backends and slow frontends from each other
> > > - so all your problems will be solved. :)
> > 
> > Will see 2.0 but I suppose that multi-threaded mod_perl backend with 10
> > threads will occupy almost the same memory as 10 mod_perl single thread
> > processes.
> But a single thread of a mod_perl backend will use less resources if it
> need only stick around for 100ms, than it will if it has to stick around
> for a minute.

Why it will stick for 100ms only with slow client ? Will Apache 2.0 use
separate threads for lingering_close ?

Igor Sysoev

Reply via email to