On 2016-03-17 00:14, Nenad Merdanovic wrote:
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.
That's indeed a noticeable performance increase on RSA but I couldn't
notice any difference for ECC.
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.
For now perhaps, but more and more sites/customer want 100% https
whether it's just cool or indeed useful doesn't matter. And I am
somewhat scared if one can take down the site with very few requests
just by disabling keep-alive and other features on the client side.
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
--
Regards,
Christian Ruppert
