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.

[EMAIL PROTECTED]                "There's a moon
                                        over Bourbon Street

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to