On Thu, Aug 4, 2011 at 10:31 AM, Aryeh Gregor <[email protected]> wrote:
> I was under the impression that the biggest cost in TLS isn't the > symmetric encryption for an ongoing connection, it's the asymmetric > encryption for the connection setup. If so, AES acceleration isn't > going to help with the most important performance issue. Am I wrong? > The handshake operations still aren't all that expensive these days, and with a prudent amount of sticky loadbalancing to ssl terminating boxes, a good hit rate can be achieved from openssl's session cache which eliminates some of the asymmetric operations and half of the connection handshake. From: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html In January this year (2010), Gmail switched to using HTTPS for everything by > default. Previously it had been introduced as an option, but now all of our > users use HTTPS to secure their email between their browsers and Google, all > the time. In order to do this we had to deploy *no additional machines* > and *no special hardware*. 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. Many people believe that > SSL takes a lot of CPU time and we hope the above numbers (public for the > first time) will help to dispel that. We can't get these sorts of numbers if we run the version of openssl bundled with lucid but everything we need is available either in patch form or has become part of the mainline openssl source. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
