EC2中的SSL缓慢

Question

我们已将rails应用程序部署到EC2。在我们的设置中，我们在循环DNS后面的小实例上有两个代理。这些运行nginx负载平衡器用于动态增长和缩小的Web服务器群。每个Web服务器还运行带有一组mongrels的nginx。这里的nginx处理静态内容并负载平衡杂种。

无论如何，我们的流量大小都是HTTPS。我们有2个代理人负责SSL。我注意到这些实例上的网络吞吐量仅为60 Mbps左右。相比之下，在测试中，我可以通过常规HTTP在小型实例上始终获得700+ Mbps。实际上，这与我在大型实例上可以得到的相同。与Right Scale家伙在their testing中得到的相似。 （亚马逊称小型网络I / O为“中等”，而大型网络I / O则为“高”。如果我不得不推测，我认为这只是他们说每个物理盒共享一个网卡的小实例我不确定这是否意味着大型网络接入专用，但我会怀疑它。）

在测试中，我能够获得一个大型实例来获得大约250 Mbps的SSL。这告诉我，CPU或其他资源是瓶颈。但是，我们的监控图表并未显示代理上的CPU特别繁忙。

我的问题是：

1. 由于CPU正确而我的监控图是错误的，我对SSL的直觉是否较慢？或者其他资源可能是限制因素吗？
2. 我们是否应该承担额外费用并将代理放在高CPU实例上？或者只是添加更多小实例会更好吗？
3. 我们应该将SSL终端卸载到Web服务器吗？这引入了另外一个问题：我们如何在我们的应用程序中获取客户端IP地址？现在我们的代理将它设置在X-FORWARDED-FOR标头中，但显然如果它不解密SSL则不可能。

我很想知道任何类似的设置。我们对他们的弹性负载均衡器进行了修改，但我认为这基本上使我们处于与上面＃3相同的情况。有没有其他人转向ELB并发现它值得吗？

Answer 1

您使用的是nginx提供的SSL会话缓存吗？这可以帮助nginx节省周期，不断重新加工加密。见http://wiki.nginx.org/NginxHttpSslModule#ssl_session_cache

您使用什么监控来确定您的cpu使用情况？ SSL通常非常占用CPU。

我会将SSL代理保留为指定层，这样您就可以将协商ssl的成本与其他问题分开。

Answer 2

我在Apache上使用SSL，它处理对小型Windows EC2实例上的Subversion存储库的访问。在测试中，我发现HTTPS访问速度比HTTP略慢，但这正是因为加密/解密不是一个瞬时过程的明显原因，正如您所期望的那样。

如果你的CPU指标是正确的并且你没有看到过多的负载，那么暗示带宽是限制因素;但是，我真的不明白为什么你可以在HTTP实例上获得700+ Mbps，而在HTTPS实例上只有60Mbps。当然，除非测试条件实际上不相同，否则HTTPS实例中还有其他内容，你没有考虑到......

较大的实例当然比Smalls获得更好的主机带宽份额 - 它们竞争资源的次数更少。由于内部EC2网络是千兆以太网，因此在大型实例上看到700Mbps是可行的，假设同一节点上没有其他大型实例正在产生类似的带宽需求。要从Small实例中获得这一点，你必须非常幸运能够在一个负载很轻的主机中运行。在这种情况下，无法保证您保持这种性能水平 - 只要其他Smalls上线，您的可用带宽份额就会开始下降。

我认为这实际上是一个小实例带宽问题 - 添加更多Smalls并不一定有用，因为你无法控制它们启动的主机;但是，大型实例可以获得更大的带宽饼，因此可能具有更一致的容量可用性。

Answer 3

SSL速度较慢： - true，然后HTTPSSL的任何正常HTTP请求都会变慢。

尝试在本地LAN上创建类似的设置，其中有3个mongrel_clust和2个webserver。 并使用curl loader检查，发送大约5k个请求。

如果一切都很好，那很好。 可能你会更加努力地与EC2人一起工作。