On Friday, April 13, 2001, at 11:21 AM, Graham Leggett wrote:
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.
Right now the multiplexer (the protocol selector) in mod_proxy.c is hardwired, so you have to touch it everytime you add a new protocol.
This particular filter should read config to know what protocols it has (or something else I forget that Victor, Ian, and I talked about last week) and be able to build the protocol processing filter chain (they won't always consist of only a content generator, consider SSL decrypt->HTTP proxy).
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.
I tend to agree with you here. Selective pooling would be a necessity if it were to be useful for the forward case, an MRU list or something else of finite size.
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.
Well, Theo (mod_backhand) might disagree with you there. So would I, as building up and tearing down the connections can be a substantial impact when the messages are short (like HTTP requests) and the net load is high. Mod_backhand does a bit of work to insure machine load stays balanced.
Another case I can think of is cache synching amongst a cluster of caches, it could be useful to pool those connections.
We can leave connection pools for later. As in put it under "would be real nice to have this, but not essential <blah blah>". I wanted to broach the topic, having talked with Theo and also gotten a couple more requests for it from folks at the Con.
Chuck Murcko Topsail Group http://www.topsail.org/
