Hello Patrick, On Fri, Jun 11, 2010 at 11:40:18PM +0200, Patrick Mézard wrote: > Hello, > > Sorry for the long email, I know there had been many threads about keep-alive > already, but I am a little confused by 1.4.7 configuration.txt > (http://haproxy.1wt.eu/download/1.4/doc/configuration.txt). I'd be happy to > improve the documentation if you help me clarify a couple of points: > > 1- "1.1. The HTTP transaction model" says: > ------- > HAProxy currently only supports the HTTP keep-alive mode on the client side, > and transforms it to a close mode on the server side. > ------- > I understand HAProxy sequences the incoming client requests and dispatches > them with a "Connection: close" header to the backends, applying dispatching > rules for every incoming request. Then "option http-server-close" seems to do > exactly this. Is it correct to say that "option http-server-close" is HAProxy > default behaviour? Or does HAProxy still works in a "parse first request > header and consider everything else data" mode when this option is not set?
haproxy still works in this second mode by default, which is internally called the "tunnel" mode, because it works exactly as it would with a CONNECT method. This is important to maintain this mode, some people rely on it to emulate end-to-end keep-alive. It is possible that we'll change the default to keep-alive once it works along the whole chain. > 2- "option httpclose" documentation states: > -------- > As stated in section 1, HAProxy does not yet support the HTTP keep-alive > mode. So by default, if a client communicates with a server in this mode, it > will only analyze, log, and process the first request of each connection. > -------- > Who is right here, 1.1 or "option httpclose"? My understanding is "option > httpclose" adds "Connection: close" header to requests from proxy to server > and to responses from proxy to client. Argh, good catch. I tried to remove all instances of "does not support keep-alive" but it was not easy and apparently some are still remaining. We should say that "unless any other option is set, haproxy will work in tunnel mode. So by default..." > 3- "option forceclose" says: > -------- > When this happens, it is possible to use "option forceclose". It will > actively close the outgoing server channel as soon as the server has finished > to respond. This option implicitly enables the "httpclose" option. > -------- > Why is actively closing proxy to server connections related to closing the > related proxy to client connection? Is it an implementation issue or by > design? It is by design. Some servers ignored the "Connection: close" request header so even with httpclose you sometimes ended up with long connections. This was a disaster because the client waited for the server to close and the server did not. So the forceclose option was meant to send an active close to the server as soon as it began to respond, so that the end of the server's response caused an immediate close of this connection, forwarded to the client. But some servers did not accept that very well (fortunately, they did not need it). Since introduction of the keep-alive support, the option has been reworked so that the active close is sent when the server has finished responding. For compatibility with previous implementations, the close is still propagated to the client. So this is not even an issue, it's the required behaviour so that we don't break existing setups. The issues, if any, are the environments that require this option. Sometimes it can be replaced by http-server-close, sometimes it cannot due to buggy clients which wait for the close. > 4- Finally, except for resource consumptions and sometimes bad server > behaviours (addressed by the pretend-keep-alive option), are there any other > drawbacks to enabling client side keep-alive with "option http-server-close" > only, other surprises? (I will probably set a 250ms http-keep-alive timeout > too, which seems to be a good tradeof). No there's no drawback and it's the best thing to do in my opinion when your clients are normal clients (browsers). The cases where we need forceclose are when hand-crafted http clients talk between servers. But when your clients are on the net, it's very much recommended to use http-server-close instead. And you're right about the short keep-alive timeout. Up to one second can be fine if you have lots of RAM. At 20000 connections per second, even if you keep an idle connection for one second, it brings you "only" 20000 concurrent connections. Regards, Willy
