Hi Malcolm, On Tue, Jul 04, 2017 at 03:27:51PM +0100, Malcolm Turnbull wrote: > It looks like some exciting stuff is on the way in haproxy-1.8-dev!
Let's hope so! > Could I ask for a bit more detail on the plans for multi-threading or > multi-process options? I'll respond myself so that it doesn't divert them too long from their keyboards (Emeric & Chris, feel free to correct me if you disagree). > For the vast majority of HTTP applications, binding one cluster to one > front end & process is fine. > > But for high traffic sites on newer hardware (Think 24 cores & 2GHz - > Not 4 core & 4GHz) you can quickly run into performance issues. > > Will it be possible for one front end to access one stick table - and > yet use multiple threads or processes? That's essentially the idea behind this. The goal with threads is to go back to the unified memory model we used to have with nbproc=1 for over a decade where everything has access to everything, but at the same time have the ability to scale on newer CPUs. Over the long term, the goal is to be able to assign a thread mask to all bind lines (like we currently do with processes), and that accepted connections try to stay affine to the thread that created them, unless there's a significant load unbalance or there are certain painful tasks to deal with (like SSL handshake) in which case a thread migration could be decided for certain sessions/streams/connections/you-name-it. Doing this will ensure that all assigned cores can be used in parallel, and that workloads sensitive to latency can continue to dedicate some cores to low-latency stuff and queue the high latency stuff on other cores. For the mid-term, we're doing baby steps. Thread migration for SSL might definitely not be the first thing implemented for example! > And if it is planned we'd be very interested in helping with testing > and or code. I hope that the guys will "soon" (ie before the 1.8 release) have something to show and share. At the moment they're still focused on reverse-engineering a lot of stuff accumulated over the last 16 years which sometimes has some strong impacts and causes some fairly long head-scratching sessions. But eventually all limitations are addressed one at a time and the progress is encouraging. I've seen some traffic flow through haproxy running on multiple cores, with a bunch of stuff disabled, but this is promising. > Sorry if this has already been discussed and I missed the conversation. No it was not really discussed, primarly to avoid putting pressure on the team so that all options could sanely be considered. We've even had some false starts due to me discussing too much with them and accidently driving them into corners. I suspect that after the holidays they'll start to be more confident in their current code (ie will not throw all of it to the trash again) and may start to discuss about how it works :-) Stay tuned! Willy
