On Sat, Oct 10, 2009 at 12:23:25AM -0700, Chris Goffinet wrote: > Not sure I understand what your asking. Why does haproxy need to > understand the protocol besides its TCP based? You can use haproxy > today for things like MySQL, etc. All I am saying is having the > ability to persist those connections, and when a client connects, one > of the free connections is given to that client.
and how do you know that a connection is "free" ? > Its very much like HTTP, stateless. No, HTTP is stateful, not stateless. In connection-close mode, the end of a transaction is detected by the close of the connection. In keep-alive mode, the end of a transaction is detected by the fact that the amount of data announced in the protocol has been transfered. And only then, the connection can be marked "free" again, not before. > It's just not using the HTTP protocol. For example if > I wanted to build a service using Protobuffers or Thrift, which > generates a custom binary protocol over TCP (changes depending on > definition) there wouldn't be a way obviously to make haproxy > understand. I am not expecting it too. Here is a patent about shmproxy > (the software I was talking about at Yahoo) > > http://www.patentstorm.us/patents/7325030/description.html > > (Of course Yahoo's solution is much involved, providing such abilities > to understanding some protocols to do things such as hashing against > Session IDs, etc, but does have generic abilities to not understand > the actual protocol) You cannot detect that a connection is not used anymore if you don't understand the protocol that passes on top of it. For instance, what makes you think that my telnet session is not used anymore and can be reused by someone else ? In my opinion, the only improvement that can be done without any knowledge of the transported protocols would just be to pre-establish connections and assign them to new clients until those connections are closed, then re-connect to the servers and put the connection back into the pool for another client. OK it could slightly reduce latency on low loads (when the connections are underused), but it would add the same downsides as common connection pools : - increased load on the remote servers due to permanent connections even when unused - inability to test if a connection is still usable before using it (it can have timed out on a firewall or layer 4 LB). - risk of triggering many request timeout errors on the remote servers when there is nothing to send on those connections. When managing real connection pools, since the proxy has to understand the upper protocol, it can multiplex connections without closing in between (when the protocol supports this), send keepalives to ensure the connection is always usable (and recycle dead ones), thus reducing some of the downsides above. Regards, Willy
