Hi,
> you're right.
> If you need to scale *a lot* your SSL processing capacity in HAProxy,
> you must use multiple processes.
> That said, multiproc model has some counter parts (stats, server
> status, health checks are local to each process, stick-tables can't be
> synchronized, etc..).
> With HAProxy 1.5, we can now start multiple stats socket and stats
> pages and bind them to each process, lowering the impact.
> That said, if stats, peers, etc matters and you still need a huge SSL
> processing capacity, then the best way is to use a first layer of
> HAProxy multi-process to decipher the traffic and make it point to a
> second layer of HAProxy in single process mode.
If that still isn't enough and you need full horizontal scalability:
Handle the SSL load with a two layered load-balancing approach. This
first layer of load-balancers only forwards in TCP mode (with source IP
stickiniess or somethings like this) and you terminate SSL/TLS at the
second load-balancing layer.
That way you achieve horizontal scalability in the second, SSL/TLS
terminating layer.
I hope that one day we can move the SSL handshake to dedicated threads,
completely eliminating the event loop blocking and allowing a single
process to forward all the traffic while some parallel threads do all
the heavy SSL handshake lifting.
Regards,
Lukas
