Hacker News new | past | comments | ask | show | jobs | submit login

> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.

This is too good to be true.




I assure you that it's true. I haven't reprofiled in that much detail since but I suspect that the numbers look even better now. Partly because computers are faster and partly because of software improvements.


I still don't understand.

1% of what? Sure, if you're doing a lot of database read/writes for every HTTP request, then yes, that makes sense. I guess it that case, the actual HTTP would account for (say) 0.1% of CPU load – which makes HTTPS 10 times slower.

I think we should compare HTTP and HTTPS connection creation/maintaining/dropping resource consumption relative to each other, not to the whole process that takes to process request, query databases, create page and send it to browser.

I'm no expert in this matter, so I could be (and probably am) completely wrong. That assertion sounded counter-intuitive to everything I've ever heard, and as it is expressed a little vague, I doubted it.


It largely depends up the nature of your web service. If you are running a user-interactive site theb i may buy it. However if you are offering a high-tps, high-throughput web service I assure you the costs of switching 100% of your users to SSL is not negligable and has a real impact on the customer experience.


I think agl is familiar with both kinds. His company tends to serve both the HTML and the APIs through the same set of load balancers.


That's a little dismissive. Perhaps we're just talking about different levels of scale.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: