HAProxy used to support multiprocess and multithread. When performance needs exceed a single cpu, you do need to do one or both of those. But a lot of HAProxy users need to share state between workers and that's a lot easier in the threaded environment.
When I had a need for HAProxy at high throughput, I ran multiprocess, and it was tricky to make sure the processes didn't try to use the same outbound addresses, among some other challenges I had to address to get to the connection numbers I thought were reasonable. I can understand why they would have chosen to go with threads only in 2.5 though.
If I was doing the same thing today, hopefully enough has changed in my chosen OS that threads would work for me, but if not, it shouldn't be too hard for me to spawn the right number of haproxy threads with individual configs to get what I need.
When I had a need for HAProxy at high throughput, I ran multiprocess, and it was tricky to make sure the processes didn't try to use the same outbound addresses, among some other challenges I had to address to get to the connection numbers I thought were reasonable. I can understand why they would have chosen to go with threads only in 2.5 though.
If I was doing the same thing today, hopefully enough has changed in my chosen OS that threads would work for me, but if not, it shouldn't be too hard for me to spawn the right number of haproxy threads with individual configs to get what I need.