> On 11 Jan 2020, at 07:48, Willy Tarreau <w...@1wt.eu> wrote:
>
> On Fri, Jan 10, 2020 at 03:17:59PM -0800, Sadasiva Gujjarlapudi wrote:
>> 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.
>
> Excellent, this is very encouraging.
>
>> 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.
>
> It should not be a problem because the "lua" struct is per-Lua instance,
> hence per-stream, so we shouldn't have that many connections per stream
> and they'll be GC'd once the Lua instance or the stream is terminated.
> And if someone runs a self-contained Lua application creating that many
> sockets and never closing them, the current situation doesn't help
> either.
I confirm: GC cleanup only object where are no longer referenced. If the
connection is global, the core.tcp object is referenced globaly and it
is not cleanned.
> What I propose if you agree is that I'll merge the patch into 2.2 next
> week. This will give us quite some time to observe if it requires more
> adjustments. And then you can pick it and apply it to your local tree
> in order to save some resources.
This is a good performance improvement. Easy and efficient !
Thierry
