Re: Haproxy nbthreads + multi-threading lua?
After a bit more research I discovered that the lua scripts are actually from signal sciences. You should have a conversation with Signal Sciences, and how they are doing ingress capture that goes through Haproxy. https://docs.signalsciences.net/install-guides/other-modules/haproxy-module/ Dave. p.s. Yes we did meet at KubeCon, and I really appreciated your suggestions on healthchecking. I just haven't had a chance to check/test them because of higher priority issues that have arisen *(isn't this always the case). And no this isn't even one fo those higher priority issues. On Wed, Dec 11, 2019 at 2:35 AM Baptiste wrote: > > On Mon, Dec 2, 2019 at 5:15 PM Dave Chiluk wrote: >> >> Since 2.0 nbproc and nbthreads are now mutually exclusive, are there >> any ways to make lua multi-threaded? >> >> One of our proxy's makes heavy use of lua scripting. I'm not sure if >> this is still the case, but in earlier versions of HAProxy lua was >> single threaded per process. Because of this we were running that >> proxy with nbproc=4, and nbthread=4. This allowed us to scale without >> being limited by lua. >> >> Has lua single-threaded-ness now been solved? Are there other options >> I should be aware of related to that? What's the preferred way around >> this? >> >> Thanks, >> Dave. >> > > Hi Dave, > (I think we met at kubecon) > > What's your use case for Lua exactly? > Can't it be replaced by SPOE at some point? (which is compatible with > nbthread and can run heavy processing outside of the HAProxy process)? > > You can answer me privately if you don't want such info to be public. > > Baptiste
Re: Haproxy nbthreads + multi-threading lua?
On Mon, Dec 2, 2019 at 5:15 PM Dave Chiluk wrote: > Since 2.0 nbproc and nbthreads are now mutually exclusive, are there > any ways to make lua multi-threaded? > > One of our proxy's makes heavy use of lua scripting. I'm not sure if > this is still the case, but in earlier versions of HAProxy lua was > single threaded per process. Because of this we were running that > proxy with nbproc=4, and nbthread=4. This allowed us to scale without > being limited by lua. > > Has lua single-threaded-ness now been solved? Are there other options > I should be aware of related to that? What's the preferred way around > this? > > Thanks, > Dave. > > Hi Dave, (I think we met at kubecon) What's your use case for Lua exactly? Can't it be replaced by SPOE at some point? (which is compatible with nbthread and can run heavy processing outside of the HAProxy process)? You can answer me privately if you don't want such info to be public. Baptiste
Re: Haproxy nbthreads + multi-threading lua?
Hi Dave, On Mon, Dec 02, 2019 at 10:12:27AM -0600, Dave Chiluk wrote: > Since 2.0 nbproc and nbthreads are now mutually exclusive, are there > any ways to make lua multi-threaded? Unfortunately no. Lua itself is inherently single-threaded and even when you believe you're using multi-threading, you end up on a big lock around all the engine that serializes everything. >From what I've found, there were several attempts to make Lua support preemptive threads, but most of them had huge limitations like not sharing anything (pointless already), they were also limited to older versions like 5.0 or 5.1. With this said, I can easily understand that something light and fast like Lua is hard to port to threads without losing all of its benefits. Are your really using it so much that it becomes a bottleneck ? I find this quite surprizing. If so, did you find any single part responsible for most of the CPU usage ? Then do you think that by moving a few of it to native code (sample fetches, converters set into variables), it could improve the situation ? Maybe you should try a trick consisting in setting tune.lua.forced-yield to a lower value (the default being 1) so that it executes much less instructions at once, leaving more room for other threads to take a share of the CPU. But in any case at a given instant you will definitely have only one thread executing Lua code. If at least you can make sure that others are not waiting too much and find other things to do with the rest of haproxy, maybe that could improve the efficiency of your program already. Regards, Willy
