On Tue, Apr 11, 2017 at 01:23:42PM +0200, Pavlos Parissis wrote: > On 10/04/2017 11:52 μμ, Olivier Houchard wrote: > > On Mon, Apr 10, 2017 at 11:08:56PM +0200, Pavlos Parissis wrote: > >> On 10/04/2017 08:09 ????, Olivier Houchard wrote: > >>> > >>> Hi, > >>> > >>> On top of those patches, here a 3 more patches. > >>> The first one makes the systemd wrapper check for a HAPROXY_STATS_SOCKET > >>> environment variable. If set, it will use that as an argument to -x, when > >>> reloading the process. > >> > >> I see you want to introduce a specific environment variable for this > >> functionality > >> and then fetched in the code with getenv(). This is a way to do it. > >> > >> IMHO: I prefer to pass a value to an argument, for instance -x. It is also > >> consistent with haproxy binary where someone uses -x argument as well. > >> > > > > I'm not sure what you mean by this ? > > It is supposed to be directly the value given to -x as an argument. > > > > Ignore what I wrote above as I was under the wrong impression that we need to > pass -x to systemd wrapper during the reload, but the systemd wrapper is not > invoked during the reload. > > > >>> The second one sends listening unix sockets, as well as IPv4/v6 sockets. > >>> I see no reason not to, and that means we no longer have to wait until > >>> the old process close the socket before being able to accept new > >>> connections > >>> on it. > >> > >>> The third one adds a new global optoin, nosockettransfer, if set, we > >>> assume > >>> we will never try to transfer listening sockets through the stats socket, > >>> and close any socket nout bound to our process, to save a few file > >>> descriptors. > >>> > >> > >> IMHO: a better name would be 'stats nounsedsockets', as it is referring to > >> a > >> generic functionality of UNIX stats socket, rather to a very specific > >> functionality. > >> > > > > Well really it is a global setting, maybe my wording isn't great, but it > > makes haproxy close all sockets not bound to this process, as it used to, > > instead of keeping them around in case somebody asks for them. > > > >> I hope tomorrow I will find some time to test your patches. > >> > > > > Thanks a lot ! This is greatly appreciated. > > > > Do you have a certain way to test it? > My plan is to have a stress environment where I fire-up X thousands of TCP > connections and produce a graph, which contain number of TCP RST received from > the client during a soft-reload of haproxy. I'll run this test against haproxy > 1.8 with and without your patches. So, I will have a clear indication if your > patches solved the issue. >
That sounds good to me. My testing involved an haproxy running with 4 processes, 2 listeners, 1000 ports for each, and 2 processes bound to each listener, 2 injectors doing http requests (that merely got a redirect as an answer from haproxy), one on each listener, and reloading haproxy in a loop. Regards, Olivier
