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. Any ideas? Cheers, Pavlos
signature.asc
Description: OpenPGP digital signature
