On Mon, Jan 04, 2010 at 07:05:48PM -0800, Hank A. Paulson wrote: > On 1/4/10 2:43 PM, Willy Tarreau wrote: > >>- 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. > > But please do have it as a separate settable timeout for situations like I > have on a few servers where 80% or more of the traffic comes from a few IPs > and if they have keep alive capability, I am willing to wait a relatively > long time (longer than the http request time out) for that connection to > send more requests - because the server spent time opening up the tcp > window to a good value for decent throughput and don't want to have to > start that process over again unnecessarily.
That's an interesting point. So basically you're confirming that we don't want a min() of the two values, but rather an override. Hank, if you're interested in trying keep-alive again, please use snapshot 20100105 from here : http://haproxy.1wt.eu/download/1.4/src/snapshot/ The only suspected remaining issue reported by Cyril seems not to be one at first after some tests. I could reproduce the same behaviour but the close_wait connections were the ones pending in the system which got delayed due to SYN_SENT retries and were processed long after the initial one, but all eventually resorbed (at least in my situation). And all the cases you reported with stuck sessions and memory increasing seem to be gone right now. Regards, Willy
