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
