On Monday 29 August 2011 10:52:29 Willy Tarreau wrote: > After this long reading, I must say I'm not fond of this at all for > several reasons : > - if a maxconn limit is too low to sustain keep-alive connections, > it will be too low to support higher response times, so the maxconn > must be raised. > > - by limiting the number of keep-alive connections to a certain amount, > you in fact prevent a number of the clients from using keep-alive > even if there would have been enough resources for this.
I agree with you but I was thinking of configurations where maxconn can't be extended as wanted. > - by preventing only new connections from using keep-alive, we create > a certain amount of unfairness between old connections and new ones. Yes and no, new connections can still switch to keep-alive if older connections were closed before the response headers were sent. This can't work for every cases but it was a trade-off between concurrency improvement and code complexity : less than 20 lines of code (without the configuration) to manage this. > I'd rather proceed differently. For the server-side keep-alive, I have > already identified the need for a list of per-server and per-backend > idle connections. I have also identified the need for a per-frontend > list of dead connections (tarpit). Similarly, we should have a list of > per-frontend idle connections. The condition to accept a new connection > would then be that the number of connections on the backend is below > (maxconn - idleconns). We would then simply close one of the older > idle connections if too many connections are already open, and take > the place. I guessed you'll suggest something different, that's why I didn't send a patch directly ;-) I thought about using a list of connections per frontend but as it didn't exist in the current haproxy code, I didn't feel comfortable to start this development when I wrote it. > That way, the impact is minimal and up to maxconn connections can use > keep-alive. And the fairness is retained, since old idle connections > will be closed instead of preventing new ones from using keep-alive. I really like the idea and it could be a great improvement for haproxy. The advantage of this solution is also that it doesn't add another keyword in the long list of possibilities haproxy offers. Also, what I see in this feature is that it will immediatly fix configurations where timeouts are forgotten (I can't say how many times I've seen instances that didn't set the http-keep-alive timeout, where it's easy to create a DoS). > If you're interested in doing this, I'd be glad to merge it and to > provide help if needed. We need a "struct list fe_idle" in the struct > proxy and add/remove idle connections there. Of course I'm interested. I can't promise I'll be available for it for the next days but I can start it shortly. -- Cyril Bonté
