On Mon, Jan 11, 2010 at 09:08:03PM +0100, Willy Tarreau wrote: > > > I mean I want client connecting to haproxy NOT to use keep-alive, > > but to utilize keep-alive between haproxy and backend servers. > > Hmmm that's different. There are issues with the HTTP protocol > itself making this extremely difficult. When you're keeping a > connection alive in order to send a second request, you never > know if the server will suddenly close or not. If it does, then > the client must retransmit the request because only the client > knows if it takes a risk to resend or not. An intermediate > equipemnt is not allowed to do so because it might send two > orders for one request. > > The problem is, the clients are already aware of this and happily > replay a request after the first one in case of unexpected session > termination. But they never do this if the session terminates during > the first request. > > So by doing what you describe, your clients would regularly get some > random server errors when a server closes a connection it does not > want to sustain anymore before haproxy has a chance to detect it. > > Another issue is that there are (still) some buggy applications which > believe that all the requests from a same session were initiated by > the same client. So such a feature must be used with extreme care. >
Imagine the following scenario: we have large number of requests from different clients. Each client send request rarely, so no need for keep-alive between client and haproxy. haproxy forwards requests to a number of backends, each request fetches rather small amount of data. Now we have rather high packet rate on proxy server, and maintaining keep alive between haproxy and backends should reduce it greatly (eliminating connection setup/shutdown sequence, all data fits into one-two data packets). This is like (dynamic) pool of connections from haproxy to backends and each request from client goes via one of already existing connection to backend (if no connection available, then new is established). I understand your arguments about edge cases with broken clients etc, but this is what config file is for :) You can enable/disable features depending on situation. What do you think about it?
