Hi Lukas,
On 2016-03-16 16:53, Lukas Tribus wrote:
The "option httpclose" was on purpose. Also the client could (during a
attack) simply do the same and achieve the same result. I don't think
that will help in such cases.
So what you are actually and purposely benchmarking are SSL/TLS
handshakes, because thats the bottleneck you are trying to improve.
You're right, yes.
First of all the selected cipher is very important, as is the
certificate
and the RSA key size.
For optimal performance, you would drop your RSA certificate
and get a ECC cert. If thats not a possibility then use 2048-bit
RSA certificates.
Your ab output suggest that the negotiated cipher is
ECDHE-RSA-AES128-GCM-SHA256 - which is fine for RSA certificates,
but your RSA certificate is 4096 bit long, which is where the
performance
penalty comes from - use 2048bit certificates or better yet use ECC
certificates.
read: DO NOT USE RSA certificates longer than 2048bit.
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.
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?
Hope this helps,
Lukas
[1] https://twitter.com/ngx_vbart/status/611956593324916736
--
Regards,
Christian Ruppert
