John-Paul, Nice to have some stats, thanks.
However the most intensive CPU part of the SSL transaction on a load balancer is the handshake (that's why we measure TPS) and as far as I'm aware AES-NI is not used in the handshake? We don't use it in our product because we couldn't find any benefit. http://blog.loadbalancer.org/ssl-offload-testing/ Very happy for someone to prove us wrong though? On 27 May 2014 05:52, John-Paul Bader <[email protected]> wrote: > Here some Benchmarks with aes-256-cbc: > > ##OpenSSL 0.9.8 > 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 165967.40k 176138.69k 178376.08k 165082.46k 178232.41k > > ### OpenSSL 1.0.1 without AES-NI (without kernel extension loaded) > 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 240935.91k 258555.73k 261316.44k 266033.49k 260849.66k > > ### OpenSSL 1.0.1 with AES-NI (without kernel extension loaded) > 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 525472.77k 545694.68k 560349.27k 557427.03k 557694.98k > > ### OpenSSL 1.0.1 with AES-NI (with kernel extension loaded) > 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > 524809.01k 548448.30k 560363.26k 555793.62k 557424.64k > > So you can see that OpenSSL will use AES-NI without the kernel extension. > I think the kernel extension is only needed on FreeBSD if you want a > /dev/aesni device. > > Kind regards, > > John > > > > Aristedes Maniatis wrote: > >> On 27/05/2014 6:59pm, Lukas Tribus wrote: >> >>> Hi, >>> >>> >>> Without purchasing specific expensive add-on cards [1], is there >>>> something specific to some modern CPUs which will accelerate SSL >>>> handling in haproxy 1.5? >>>> >>>> That is, should I be looking for something in a CPU which will >>>> improve performance considerably? There is an Intel instruction >>>> set called AES-NI but I don't know if that applies to HTTPS# >>>> traffic. As I understand, the initial negotiation in SSL is rsa/dsa >>>> but then the payload is transported using symmetric key encryption >>>> (like AES?). >>>> >>>> I'm only looking to handle about 50Mb/s of SSL traffic, so I'm not >>>> aiming very high. But it would be nice to know the headroom is there. >>>> >>> Bandwidth is not really the limiting factor, handshakes per second is. >>> AES-NI gives you a nice performance boost but doesn't help with >>> handshakes >>> afaik. >>> >>> Whats important, among other points, is having enough entropy, and the >>> RDRAND >>> feature of modern CPUs can help you there (if you trust your CPU vendor). >>> >>> Otherwise, there some software projects like haveged or audio entropy >>> daemon >>> that can feed random data in the kernel. >>> >>> >>> Keep-alive and session id resumption are very important features to scale >>> a SSL enabled site, so double check that those things are working >>> properly. >>> >> >> >> Right, so then it isn't about AES at all, but the public key negotiation >> and key generation. We are running on Freebsd 10 which feeds /dev/random >> from yarrow and that in turn grabs entropy from the CPU and other places. >> So I think we should be good since we are unlikely to run out of entropy >> there. >> >> aesni_load="YES" in loader.conf should take care of the AES side of things >> >> If the NSA wanted credit card numbers they could just go get them from >> Mastercard directly, and there isn't really much else of great espionage >> interest in the transactional data. So I'm not overly concerned about the >> backdoors in the Intel CPUs. >> >> >> Thanks for the useful information. >> >> >> Ari >> >> >> >> > -- > John-Paul Bader | Software Development > > www.wooga.com > wooga GmbH | Saarbruecker Str. 38 | D-10405 Berlin > Sitz der Gesellschaft: Berlin; HRB 117846 B > Registergericht Berlin-Charlottenburg > Geschaeftsfuehrung: Jens Begemann, Philipp Moeser > > -- Regards, Malcolm Turnbull. Loadbalancer.org Ltd. Phone: +44 (0)870 443 8779 http://www.loadbalancer.org/
