Just saw this:
http://shader.kaist.edu/sslshader/
As we move to offer "real" https access, maybe this could help keeping the CPU cost down?
Magnus Manske wrote:
Just saw this:
http://shader.kaist.edu/sslshader/
As we move to offer "real" https access, maybe this could help keeping the CPU cost down?
Our servers don't have a GPU, so that would need a hardware upgrade.
On Fri, Jul 29, 2011 at 11:29, Platonides Platonides@gmail.com wrote:
Our servers don't have a GPU, so that would need a hardware upgrade.
Yes, but if large scale SSL deployment increased CPU usage to the point
of necessitating new hardware... the cost could be reduced by purchased GPU's for servers rather than bunches of entirely new boxes.
Conceptually I think it is a cool idea.
On Fri, Jul 29, 2011 at 11:53 AM, Jon Davis wiki@konsoletek.com wrote:
On Fri, Jul 29, 2011 at 11:29, Platonides Platonides@gmail.com wrote:
Our servers don't have a GPU, so that would need a hardware upgrade.
Yes, but if large scale SSL deployment increased CPU usage to the point
of necessitating new hardware... the cost could be reduced by purchased GPU's for servers rather than bunches of entirely new boxes.
Conceptually I think it is a cool idea.
Most likely we'll end up with dedicated SSL termination subcluster, so those machines could be grabbed with whatever hardware they specifically needed. Certainly something to keep in mind!
-- brion
Hey,
I looked at this a little while ago for a previous job. I think that it's a pretty awesome idea, but sadly I could never even find source for their research, much less any reports of it being successfully deployed in the wild, which made me sad. Hopefully they'll release it and then some people here could go to town on it!
Best, Peter
On Fri, Jul 29, 2011 at 12:10 PM, Brion Vibber brion@pobox.com wrote:
On Fri, Jul 29, 2011 at 11:53 AM, Jon Davis wiki@konsoletek.com wrote:
On Fri, Jul 29, 2011 at 11:29, Platonides Platonides@gmail.com wrote:
Our servers don't have a GPU, so that would need a hardware upgrade.
Yes, but if large scale SSL deployment increased CPU usage to the point
of necessitating new hardware... the cost could be reduced by purchased GPU's for servers rather than bunches of entirely new boxes.
Conceptually I think it is a cool idea.
Most likely we'll end up with dedicated SSL termination subcluster, so those machines could be grabbed with whatever hardware they specifically needed. Certainly something to keep in mind!
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Aug 4, 2011 at 2:13 AM, Peter Youngmeister py@wikimedia.org wrote:
Hey,
I looked at this a little while ago for a previous job. I think that it's a pretty awesome idea, but sadly I could never even find source for their research, much less any reports of it being successfully deployed in the wild, which made me sad. Hopefully they'll release it and then some people here could go to town on it!
I talked to Maarten Dammers at Wikimania yesterday, and he mentioned that he's using some sort of netapp (a load balancing appliance) at work that has SSL termination built in, in hardware. It sounded pretty cool, but he also warned those things are pretty damn expensive.
Roan
On 04/08/11 13:46, Roan Kattouw wrote: <snip>
I talked to Maarten Dammers at Wikimania yesterday, and he mentioned that he's using some sort of netapp (a load balancing appliance) at work that has SSL termination built in, in hardware. It sounded pretty cool, but he also warned those things are pretty damn expensive.
There are plenty of load balancing appliances we could use. They can also handle: - geographical redirection - local load balancing - maintenance page - HTTP compression Some can be used as DNS proxies and for DOS protection / firewall.
I think Mark deployed some foundry switchs from Brocade. That vendor also have load balancing appliances.
From the orig post "Recent Intel CPU has a fature called
AES-NIhttp://en.wikipedia.org/wiki/AES_instruction_set that accelerates AES processing. A CPU with AES-NI can perform 5 to 10 times faster than a CPU without it. We observe that a single core can perform 5 Gbps and 15 Gbps for encryption and decryption respectively." There's no longer a need for specialized hardware solutions in this space, GPU based or otherwise.
On Fri, Jul 29, 2011 at 12:10 PM, Brion Vibber brion@pobox.com wrote:
On Fri, Jul 29, 2011 at 11:53 AM, Jon Davis wiki@konsoletek.com wrote:
On Fri, Jul 29, 2011 at 11:29, Platonides Platonides@gmail.com wrote:
Our servers don't have a GPU, so that would need a hardware upgrade.
Yes, but if large scale SSL deployment increased CPU usage to the point
of necessitating new hardware... the cost could be reduced by purchased GPU's for servers rather than bunches of entirely new boxes.
Conceptually I think it is a cool idea.
Most likely we'll end up with dedicated SSL termination subcluster, so those machines could be grabbed with whatever hardware they specifically needed. Certainly something to keep in mind!
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Aug 3, 2011 at 11:10 PM, Asher Feldman afeldman@wikimedia.org wrote:
From the orig post "Recent Intel CPU has a fature called AES-NIhttp://en.wikipedia.org/wiki/AES_instruction_set that accelerates AES processing. A CPU with AES-NI can perform 5 to 10 times faster than a CPU without it. We observe that a single core can perform 5 Gbps and 15 Gbps for encryption and decryption respectively." There's no longer a need for specialized hardware solutions in this space, GPU based or otherwise.
All the hardware we are purchasing for the SSL clusters has this support, as well.
- Ryan
(Sorry if this winds up getting to the list twice, resending because I think the first got lost in a moderation queue or something.)
On Thu, Aug 4, 2011 at 2:10 AM, Asher Feldman afeldman@wikimedia.org wrote:
From the orig post "Recent Intel CPU has a fature called AES-NIhttp://en.wikipedia.org/wiki/AES_instruction_set that accelerates AES processing. A CPU with AES-NI can perform 5 to 10 times faster than a CPU without it. We observe that a single core can perform 5 Gbps and 15 Gbps for encryption and decryption respectively." There's no longer a need for specialized hardware solutions in this space, GPU based or otherwise.
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?
On Thu, Aug 4, 2011 at 10:31 AM, Aryeh Gregor ayg@aryeh.name 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@lists.wikimedia.org