Hi, On Fri, Jun 20, 2014 at 12:38:48PM +0200, Lukas Tribus wrote: > Hi, > > > > Is it possible to use HTTP keep-alive between haproxy and > > backend even if client does not use it? > > Client closes connection, but haproxy still maintains open > > connection to backend (based on some timeout) and re-use it > > when new request arrives. > > > > It will save some time for new connection setup between haproxy > > and backend and can be useful in case when server responds > > very fast (and connection rate it high). > > That would be connection pooling/multliplexing and is not currently > supported. It is also pretty complex, not sure whether this is > something that will be done in 1.6.
I would like to be able to do this in 1.6, but it's not high on the priority list. The way the code is now architected makes it less complex than what it used to be, the real issue is to do it right. I even hesitated to try to work on it after the server-side KA started to work. In practice, you must not send a request over an already established connection if it's a non-idempotent request (eg: a POST) or if you're not able to safely replay it yourself or are not certain the client can replay it (eg: not the first request of a connection). Replaying an already sent idempotent request could more or less be achieved under some conditions. The worst problem we have to face now is that once a buffer is emptied, it's realigned so we lose its origin. But with an extra "do-not-realign" flag, we could possibly keep the request in the buffer. There are other issues with connection pools. Connections can die the dirty way (eg: not used over a period and expire through a firewall). So you have to test them periodically. Health checks are not necessarily sufficient for this since they're too slow or will hammer the server. One solution can be to limit a connection's max idle time to a few seconds (it's a waste of resources otherwise anyway). I think we'll get it in 1.6 but we need to be careful about what we do. Regards, Willy
