After applying Willy's patch
requests/sec 7181.9869
$time haproxy
real 0m10.304s
user 0m1.112s
sys 0m1.184s
After applying Willy's patch and the following patch
@@ -955,10 +956,14 @@ void hlua_ctx_destroy(struct hlua *lua)
* the garbage collection.
*/
if (lua->flags & HLUA_MUST_GC) {
- if (!SET_SAFE_LJMP(gL.T))
- return;
- lua_gc(gL.T, LUA_GCCOLLECT, 0);
- RESET_SAFE_LJMP(gL.T);
+ if (lua->gc_tune_count++ > 1000) {
+ lua->gc_tune_count = 0;
+ if (!SET_SAFE_LJMP(gL.T))
+ return;
+ lua_gc(gL.T, LUA_GCCOLLECT, 0);
+ RESET_SAFE_LJMP(gL.T);
+ }
+
}
requests/sec 8635.0402
real 0m10.969s
user 0m0.744s
sys 0m1.116s
Most of the time the CPU is the bottleneck and it may be ok to consume
little bit more memory on dedicated servers running haproxy.
Our use case/Lua application required to use as little CPU as possible.
Thankyou for the great product and your support !
Regards,
sada
On Thu, Jan 9, 2020 at 2:03 AM Willy Tarreau <w...@1wt.eu> wrote:
>
> On Thu, Jan 09, 2020 at 10:56:59AM +0100, Thierry Fournier wrote:
> > >> Maybe we try to include new option "tune.lua.forced-gc".
> > >
> > > Based on your description if we need an option, I'd rather have the
> > > opposite, like "tune.lua.disable-gc" so that it remains enabled by
> > > default, and with an explanation that one must not disable it.
> >
> >
> > I agree, but it make sense to run some tests:
> >
> > - First, testing your patch to decide if the GC line 1195 is relevant
> > - Second, testing the behavior when GC is disabled and lua create
> > connexion and lua fail without closing connexion.
> >
> > Maybe the second case make the GC mandatory.
>
> Probably but then it should only be needed in hlua_ctx_destroy(), no ?
> My understanding is that the only goal is to be sure to kill such an
> orphan connection in case the Lua application dies, so I tend to think
> it's never needed in resume (I don't see how we'd resume after dying)
> and that hlua_ctx_destroy() should always be called for the cleanup so
> it should possibly be enough.
>
> Willy
