After applying the patch and socket wasn't `close`d in Lua code request/sec 7898.0976 $time haproxy real 0m6.689s user 0m1.043s sys 0m1.059s
After applying the patch and socket was `close`d in Lua code requests/sec: 9617.4609 $time haproxy real 0m7.505s user 0m0.738s sys 0m0.930s Same machine, no Lua code running requests/sec: 14468.4468 $time haproxy real 0m17.265s user 0m0.243s sys 0m0.670s Also tested by causing the runtime error in Lua code before `close`ing the socket. $ulimit -n 6000 Lua action/app created 20K connections during the test and everything seems to be working as expected. My only concern with this patch is what if there is a persistent connection and `conn_count` is always greater than zero and that triggers GC. Regards, sada. On Fri, Jan 10, 2020 at 1:19 AM Willy Tarreau <w...@1wt.eu> wrote: > > On Fri, Jan 10, 2020 at 09:40:09AM +0100, Thierry Fournier wrote: > > I like this way. If the Lua program works perfectly, the GC is not forced. > > If some connections are pending the GC start and clean up. > > > > Maybe it is must clever to rename the variable from "conn_count" to > > "require_gc_count". By this way if another resource have the same problem > > than TCP connections, this var could be used ? > > Excellent suggestion, you're totally right! > > > For testing this patch we need three cases: > > > > - The Lua program work perfectly. > > > > - The Lua program must fail after connexion (something like this: > > unexistant_array['void_key'] = 1). This test the unexpected abort. If the > > Lua fails, we must validate the socket is closed and HAProxy is not > > blocked > > because no connection available. > > > > - The socket close must be commented out. The same kind of test than > > previsouly, > > but without the bug. > > Well, I think it's too advanced for me, I'm just able to propose patches > here :-) > > Willy
