Thank you for turning that around so quickly, Willy. We'll pull down the new release when it's available.
-----Original Message----- From: Willy Tarreau <w...@1wt.eu> Sent: Tuesday, October 22, 2019 10:53 PM To: Brian Diekelman <bdiekel...@godaddy.com> Cc: haproxy@formilux.org Subject: Re: Lock contention in pat_match_str in threaded mode Notice: This email is from an external sender. Hi Brian, On Tue, Oct 22, 2019 at 04:19:58PM +0200, Willy Tarreau wrote: > At the moment I don't know what it requires to break it down per > thread, so I'll add a github issue referencing your report so that we don't > forget. > Depending on the complexity, it may make sense to backport it once > done, because it's still a regression. So this morning I spent a little time on it and it was really trivial to fix. I've now splitted the LRU cache per thread (just as it is when using nbproc in fact) so that we can get rid of the lock. Result, from 67kH/s I jump to 369kH/s on a test with 7 threads on 4 cores :-) I could backport it as far as 1.8 so I did it, as I really consider this as a regression and it can be a showstopper for some users to migrate to threads. The gains are less important in 1.8 since the scalability is much less linear there. I'm going to work on issuing some releases today or over this week, I'd encourage you to migrate to 2.0.8 once it's out. Thanks again for your detailed report! Willy
