Using HAproxy in multi core environments

HAproxy is a great load balancing solution that we use at Instela. We use HAProxy in a 8-Cores bare metal machine and we also use it to offload SSL encryption.

Although HAproxy is very effective solution in terms of CPU usage, SSL offloading obviously needs more CPU power, thus, using only one core could be easily a bottleneck. Apart from this, also we did not want to waste other cores and we decided to activate not recommended multi core support.

The configuration is pretty straightforward. At the global section of haproxy.cfg, we put these directives:

nbproc 15
cpu-map 1 1
cpu-map 2 2
cpu-map 3 3
cpu-map 4 4
cpu-map 5 5
cpu-map 6 6
cpu-map 7 7
cpu-map 8 8
cpu-map 9 9
cpu-map 10 10
cpu-map 11 11
cpu-map 12 12
cpu-map 13 13
cpu-map 14 14
cpu-map 15 15
stats bind-process 15

These directives tells HAProxy to use 15 threads (we have 16 virtual cores and we leave one of them free) and assigns each thread to a core.

The magic happens when we define frontends. bind-process directive at frontend section allows us to assign each frontend to a specific thread. For instance, we have a non-HTTPS frontend which is redirecting non-HTTPS traffic to HTTPS one and we assigned only one thread to this frontend:

frontend instela mode http

On the other hand our heaviest frontend is dealing with the HTTPS traffic and SSL offloading, therefore we assigned the most of our threads to this frontend:

frontend instela-ssl mode http option forwardfor except option httplog option http-server-close bind-process 2 3 4 5 6 7 8 9 10 11

And our other threads are assigned to another frontends that has lighter traffic.

The configuration is so easy. But there are some important things to be considered when we use HAproxy in multithreaded mode. You must be aware that every thread has its own memory area and they are not aware of each other. We can see this phrase in the HAproxy documentation more than once:

Note : Consider not using this feature in multi-process mode (nbproc > 1) unless you know what you do : memory is not shared between the processes, which can result in random behaviours.

The most common problem that we faced was that our backend servers were receiving multiple HTTP check requests. In the beginning we did not find out the reason of these unnecessary requests but after a while we realized that every thread was checking backend availability on its own because they were not be able to share the availability information between each other.

If you can ignore this random behaviour and you do not heavily need the statistics feature, you can use HAproxy in multithreading mode as we do.

Cagatay Gurturk’s Blog

My personal blog where I share stuff about IT, mostly about…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store