More nginx/stunnel ssl testing | Hacker News Reader

More nginx/stunnel ssl testing

nginx.org

45 pointsnginxorg8 comments

I'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.

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.

I can't agree more :)

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.

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.

Real SSL clients are supposed to use SSL session resumption. Benchmarking with a client that only negotiates new sessions hardly reflects real-life usage.

Reply on news.ycombinator.com