【问题标题】:SSL slowness in EC2EC2 中的 SSL 缓慢
【发布时间】:2010-04-16 22:24:52
【问题描述】:

我们已将 Rails 应用部署到 EC2。在我们的设置中,我们在循环 DNS 后面的小实例上有两个代理。它们运行 nginx 负载均衡器,用于动态增长和缩小的 Web 服务器群。每个 Web 服务器还运行带有 杂种集群的 nginx。这里的 nginx 负责静态内容和负载均衡。

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

在测试中,我能够让一个大型实例获得大约 250 Mbps 的 SSL。这对我说 CPU 或其他资源是瓶颈。但是,我们的监控图并没有显示我们代理上的 CPU 特别繁忙。

我的问题是:

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

我很想听听任何类似的设置。我们对他们的 Elastic Load Balancer 进行了一些修改,但我认为这基本上使我们处于与上述 #3 相同的情况。有没有其他人改用 ELB 并觉得值得?

【问题讨论】:

    标签: ruby-on-rails ssl amazon-ec2 nginx amazon-web-services


    【解决方案1】:

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

    您使用什么监控来确定您的 CPU 使用率? SSL 通常占用大量 CPU。

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

    【讨论】:

      【解决方案2】:

      我在 Apache 上使用 SSL,它处理对小型 Windows EC2 实例上的 Subversion 存储库的访问。在测试中,我发现 HTTPS 访问比 HTTP 慢一点,但这显然是因为加密/解密不是您所期望的即时过程。

      如果您的 CPU 指标是正确的并且您没有看到负载过大,那么这意味着带宽是限制因素;但是,我真的不明白为什么你可以在 HTTP 实例上获得 700+ Mbps,而在 HTTPS 实例上只有 60Mbps。当然,除非测试条件实际上并不相同,并且 HTTPS 实例内部还有其他事情发生在您没有考虑在内...

      当然,与 Smalls 相比,较大的实例会获得更好的主机带宽份额 - 竞争资源的实例更少。由于内部 EC2 网络是千兆以太网,假设同一节点上没有其他大型实例提出类似的带宽需求,在大型实例上看到 700Mbps 是可行的。要从小型实例中得到它,您必须非常幸运地在负载非常轻的主机中运行。在这种情况下,无法保证您会保持该性能水平 - 一旦其他 Smalls 上线,您在可用带宽中所占的份额就会开始下降。

      我认为这本质上是一个 Small 实例带宽问题 - 添加更多 Smalls 不一定有太大帮助,因为您无法控制它们在哪个主机上启动;然而,大型实例会在带宽蛋糕中获得更大的份额,因此可能具有更一致的容量可用性。

      【讨论】:

        【解决方案3】:

        SSL 变慢:- 是的,那么任何正常的 HTTP 请求 HTTPSSL 都会变慢。

        尝试在本地 LAN 上创建一个类似的设置,其中您有 3 个 mongrel_clust 和 2 个网络服务器。 并使用 curl 加载程序进行检查,发送大约 5k 个请求。

        如果一切正常,那就太好了。 可能你会更努力地与 EC2 人员一起工作。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2018-03-19
          • 2023-04-01
          • 2016-10-24
          • 2018-10-16
          • 2019-04-08
          • 1970-01-01
          • 2018-05-24
          相关资源
          最近更新 更多