Hello, On 3/16/2016 6:25 PM, Christian Ruppert wrote: > > Some customers may require 4096 bit keys as it seems to be much more > decent than 2048 nowadays. So you may be limited here. A test with a > 2048 bit Cert gives me around ~770 requests per second, a test with an > 256 bit ECC cert around 1600 requests per second. That's still more than > 96% difference compared to non-SSL, way better than the 4096 bit RSA one > though. I also have to make sure that even some older clients can > connect to the site, so I have to take a closer look on the ECC certs > and cipher then. ECC is definitively an enhancement, if there's no > compatibility problem.
HAproxy can, in latest versions, serve both ECC and RSA certificates depending on client support. In a fairly large environment I have found that about 85% of clients are ECC capable. Also, look at configuring TLS ticket keys and rotating them properly as well as using keepalive. The difference in performance you are observing is fairly normal. You can measure the SSL performance of your CPU using 'openssl speed' to see how many computes/s you get without the HAproxy penalty, but the numbers should be very close. Another thing you might consider is switching to OpenSSL 1.0.2 because you have a v3 Intel Xeon which has AVX2 instruction support and will benefit from improvements done in 1.0.2. In an SSL-heavy environment, we use servers with a lot of cores, albeit slower per core, and with a good DDoS-protection ruleset haven't experienced any attacks that weren't effectively mitigated. With a properly configured SSL stack in HAproxy (all of the things mentioned above), the CPU usage difference is almost negligible. And to be honest, there are not that many SSL-exhaustion attacks. > >> >> >> Both nginx [1] and haproxy currently do not support offloading TLS >> handshakes to another thread or dedicating a thread to a TLS session. >> >> Thats why Apache will scale better currently, because its threading. > > Hm, I haven't tried Apache yet but would that be a huge benefit compared > to a setup using nbproc > 1? No :) Your CPU can only give as much. Regards, Nenad
