More nginx/stunnel ssl testing
nginx.org
More nginx/stunnel ssl testing
1–10 of 11 posts
Re: More nginx/stunnel ssl testing
#2I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par.
tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
Re: More nginx/stunnel ssl testing
#3I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
Completely agree.
When deploying Rackspace Cloud Files (Openstack swift), we tested several SSL-terminating load balancers (throughput, not connection/sec), and we found the best performance with Zeus. Pound was the best in our tests for open source.
Re: More nginx/stunnel ssl testing
#4I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
A few years back, I tested cyassl http://1nw.eu/!f8 for RSA computation (a friend of mine had patched it to remove a lot of malloc and optimize the code, something he couldn't do on openssl). It had interesting results compared to OpenSSL, but I haven't tried to use it with a real daemon.
Does anybody know if it would compile with nginx/stunnel/stud ? Results would be interesting.
Re: More nginx/stunnel ssl testing
#5I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
I can't agree more :)
Re: More nginx/stunnel ssl testing
#6I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
To some extend I agree - but if it wasn't for this benchmark AND the follow-up, my SSL cipher list would definitively not be the first (or second, or third) item I'd check in case of mysterious web server slowness ... Now it is.
I've learned something from this and thus find it useful.
Re: More nginx/stunnel ssl testing
#7I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
[deleted]
Re: More nginx/stunnel ssl testing
#8I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
Very true, but in the process I've learned a lot about SSL and nginx.
Re: More nginx/stunnel ssl testing
#9I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
If that's the case ... then it's a real problem.
The mainstream argument lately has been that SSL is so minimally computationally intensive that it doesn't hurt to just use it by default for all of your traffic. If piping your traffic through SSL is so computationally intensive that it dominates your entire cross-webserver benchmark ... then the mainstream argument can't possibly be true.
Re: More nginx/stunnel ssl testing
#10I'd just like to go on the record to say, chances are that what we're all benchmarking here (stunnel/stud/nginx) is essentially openssl--and that, unsurprisingly, when we use whatever contortions are necessary to get OpenSSL set up in identical configurations within each daemon, the results are roughly on par. tl;dr -- we can probably all stop doing these benchmarks since we're largely benchmarking the same thing.
If that's the case ... then it's a real problem. The mainstream argument lately has been that SSL is so minimally computationally intensive that it doesn't hurt to just use it by default for all of your traffic. If piping your traffic through SSL is so computationally intensive that it dominates your entire cross-webserver benchmark ... then the mainstream argument can't possibly be true.
SSL is so minimally computationally intensive that it doesn't hurt to just use it by default for all of your traffic
May I ask where you got that from ?
SSL, or to be more accurate RSA, IS computationally intensive, but mostly at the establishment of the session (you cannot do millions of multiplications on a consumer grade CPU without expecting some delay and heat).
Once the connection is established, and can be reused/resumed, it's relatively cheap.