Here's an interesting blog post by a Google engineer about how they rolled out SSL for many of their services with very little additional CPU and network overhead. Specifically, he claims that
"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." http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html -Bryan On Fri, Nov 19, 2010 at 4:54 AM, Willy Tarreau <w...@1wt.eu> wrote: > > On Wed, Nov 17, 2010 at 09:46:05AM -0500, John Marrett wrote: > > Bedis, > > > > > Cause using the cores to decrypt traffic would reduce drastically > > > overall performance. > > > Well, this is what we saw on our HTTP cache server (running CentOS) on > > > 8 cores hardware: when enabling SSL, the performance were so bad that > > > > > So we kept our old Nortel vpn 3050 to handle the SSL traffic. > > > > I'm astonished to hear that you had these kinds of issues on modern > > hardware. We stopped using dedicated SSL hardware quite some time ago. > > I'm not surprized at all. The issue generally lies in mixing high latency > processing (eg: SSL) with low latency (eg: HTTP processing). When your > CPUs are stuck for 200 microseconds processing an SSL connection, you > can try to do whatever you want, all pending HTTP processing will be > stuck that long, which will considerably limit the request rate. > > One of the solution sometimes is to dedicate some CPUs to slow processing > and others to fast processing, but this is not always possible. > > Cheers, > Willy > >
