Chuck Murcko wrote:
> Mod_proxy.c has to get redone as a filter to really do this in a way
> that you don't add code to it every time you write a new protocol
> filter.
Why? A filter takes a bucket brigade, optionally does something to it,
then passes it to the next filter in the stack. The MPR modules are
content generators, sourcing data from some location (FTP, LDAP, SQL,
HTTP, whatever), turning them into bucket brigades, then passing them up
the stack.
> Plus we need to talk about how to get rid of the proxy: hack so
> the server core can finish getting protocol neutral.
True...
> Connection pooling would be nice to have, but is simplest to do and most
> useful in reverse proxies. Connection pooling in a forward proxy is more
> interesting, but harder to do efficiently.
Having thought about it connection pooling isn't that good an idea. In
the forward proxy situation each connection ties up a backend server
process regardless of whether it is being used or not. The slight gain
you get on the frontend is hugely compromised by the huge resource drain
on the backend. In the reverse proxy situation connection pools break
load balancing. Where there are more than one backend server, only one
server ends up taking all the load. In addition to this most of the time
in a reverse proxy situation, the backend and frontend are usually
connected via a fast LAN - so connection pooling isn't going to make
much of an impact on LAN performance anyway.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
