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?
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.
> > 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.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
smime.p7s
Description: S/MIME Cryptographic Signature
