Hi Gerd, On Wed, Jun 29, 2016 at 08:55:28AM +0000, Gerd Mueller wrote: > Hi list, > > I am about to plan the update of our loadbalancing infrastructure. Before I > start I would like to get your comments and recommendations. Right now I > would like to install a two node cluster based on CentOS7 and haproxy 1.6. > Because SSL is more and more important the new setup should be able to handle > a lot of concurrent ssl connections. I haven't done all of my homework yet > but I guess I need to be able to handle about 200k concurrent connections > (about 80% ssl). > > So anybody any suggestions for me?
A few hints : - 200k concurrent connections will consume up to 6.4 GB of RAM for haproxy and about half of that for the kernel (2*16kB for haproxy, 4*4kB for the kernel buffers) - the 160k concurrent SSL connection you expect will add another ~92kB per connection, or about 15 GB. => you're at about 25 GB of total RAM just to handle the traffic. These 160k SSL connections will necessarily take some time to establish, so I hope for you these are long connections. Modern CPUs with openssl 1.0.2 can compute around 1k RSA2048 keys per second per core at 3.5 GHz. So a 4-core 3.5 GHz CPU will reach at best 4k SSL conns per second. On such a platform it would take 40 seconds of pure CPU time just to perform all the handshakes needed to reach the 160k concurrent conns. You'd better have ultra-long sessions and not fail-over too often on another node. I'd instead suggest to install multiple boxes to reduce the load per box and to limit the amount of renegociation in case of failure. Sharing TLS secrets to limit reneg is almost mandatory here by the way. Regarding the OS, use either Linux or FreeBSD which are the only ones who can scale properly to such connection counts by using epoll or kqueue. Regardless of the OS you'll need to perform a lot of tuning to ensure that your performance remains smooth all over the range. And never underestimate the risk of source port shortage to reach your servers. Hoping this helps, Willy
