Hi Cyril, On Mon, Jan 04, 2010 at 10:21:40PM +0100, Cyril Bonté wrote: > Hi Willy, > I didn't have much time for tests but I can make some first feedbacks.
That's fortunate because I spent the day again chasing some remaining CLOSE_WAIT issues. I finally found horrified that the response parser which for a long time was the last analyser did not set a correct return code, making it impossible for the forwarded to see the data pass the first time. Also my fears on the ugly state machines were founded. I found several cases where they could not work. So I have reworked them as I initially wanted to except that this time I found how to :-) 1.4-dev5-6 is running fine now on two servers. I'm letting it running for some time now, but I'm more confident. Before I would not understand why it worked but now when something does not, it becomes harder to believe, which is a good sign ;-) That version will be available in the snapshot dir 5 hours from now. > Le Lundi 4 Janvier 2010 00:13:49, Willy Tarreau a écrit : > > The keep-alive timeout is bound to the http-request timeout right now, > > In practice, this is the minimum value between the "http-request timeout" and > the "client timeout". yes indeed. But there's not point setting http-request lower than the other one. > > but I'm thinking about adding a new timeout for this one, so that we > > can lower it even more (eg: a few tens or hundreds of milliseconds). > > Good idea. > > In the documentation, the "http-server-close" section should recall that the > timeouts are *very* important. > Imagine a configuration with no client timeout and no http-request timeout : Such a config already emits a warning. It's still supported by compatibility with version 1.1 which used to work that way by default, but I think that sooner or later I will simply render such a configuration invalid and refuse to start. It is mandatory to have all of these timeouts right now : - connect - client - server > in "tunnel" mode, keep-alive connections were generally closed by the timeout > managed by the backend server (Apache KeepAliveTimeout, ...) > but in "server-close" mode, the client side connection will never be closed > (never or until the user decides to stop browsing the site), which can > shortly lead to a DoS. yes, but you don't even need a DoS, only a firewall in the way and you're certain to saturate your session table sooner or later. > - Maybe this new timeout should have a default value to prevent infinite > keep-alive connections. > - For this timeout, haproxy could display a warning (at startup) if the value > is greater than the client timeout. In fact I think that using http-request by default is fine and even desired. After all, it's the time we accept to keep a connection waiting for a request, which exactly matches that purpose. The ability to have a distinct value for keep-alive is just a bonus. > > Oh BTW I've removed the limits on the numbers of config files (...) > > Nice, have you planned to add a "include" keyword in the global section ? I initially wanted to but finally refrained when I decided to support multiple files on the command line. The reason is very simple : the command line is sequential. Includes are recursive with lots of risks to loop and many controls to perform. So finally I thought that it was not worth the trouble. > > As usual, have fun and please report any positive or negative experience ! > > Well, haproxy 1.4 looks very promising ;) I hope so ! But from my side, it's almost a nightmare. I knew that keep-alive was very difficult, I was prepared to that but even my darkest nightmares on the subjects were nicer than reality :-) Best regards, Willy
