On 15/03/2017 11:48 πμ, Cyril Bonté wrote: > Hi all, > >> De: "Willy Tarreau" <[email protected]> À: "Robson Roberto Souza Peixoto" >> <[email protected]> Cc: [email protected] Envoyé: Mardi 14 Mars >> 2017 13:20:46 Objet: Re: Force connection close after a haproxy reload >> >> On Tue, Mar 14, 2017 at 11:16:26AM +0000, Robson Roberto Souza Peixoto >> wrote: >>> But will `-st` mode wait for current http requests finish? Or will >>> interrupt all connections without waiting for the responses? >> >> It will interrupt them all but you said you were running TCP and not HTTP >> so with TCP there's no notion of end of request nor response. > > As a reminder (to me), I sent a patch in december (just before the 1.7.0 > release), which immediately closes the HTTP keep-alived connections. > Currently, during the soft stop, HTTP connections are only closed when a > request is processed, it doesn't do anything on connections already in an > idle state. I didn't spend more time on it but having a quick look at it, it > may be ready to merge soon. >
What I have observed in production is that in HTTP mode the timeout settings (client, http-requests) contribute to how long older process stay around. Longer timeouts makes older processes to stay around longer time. Having said this, it all depends to the traffic composition. For instance, when you have radio streaming then older processes stay for days regardless to timeout settings. > About TCP connections, while I wrote the patch, I was thinking about a global > "grace timeout", which will enforce haproxy exit if the soft stop takes too > long (for example when tcp connections don't expire). Something like : > > global grace 30s This is a very interesting approach, as it solves the issue of old processes staying around for days for TCP mode. +1 from me. Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
