3

我有一个简单的 Django 应用程序，我一直在用 Blitz.io 进行测试。当我使用许多 dynos 进行测试时，我可以在 http://X.com 上获得数千个 req/s 当我切换到 https://X.com 时，无论有多少 dynos，我都不会超过 72 req/s。在 https://X.herokuapp.com/ 上我得到了更多，但它仍然以几百个 req/s 最高。

这是不会出现在正常用例中的侥幸吗？闪电战问题？一个heroku问题？资源会随着需求而扩大吗？

4

2 回答 2

2

我们在 blitz.io 和 loader.io 上遇到了非常相似的问题。有关更多详细信息，请参阅我们在http://making.fiftythree.com/load-testing-an-unexpected-journey/上的博客文章。blitz.io 很可能是您的 SSL 问题的原因。我们发现BlazeMeter可以很好地处理负载。

如果成本是一个问题，您可能还想尝试开源工具，如siege或JMeter。

于 2013-10-12T16:01:37.357 回答
1

此答案假定https://X.com使用 SSL:endpoint heroku 插件来提供自定义证书。

ssl:endpoint 插件是使用 AWS Elastic Load Balancer 实现的。ELB 使用 DNS 在其节点之间分配负载。以我的经验，每个单独的 ELB 节点并不是特别强大，从 CPU 的角度来看，SSL 协商/解密并非易事。因此，在进行负载测试时，重要的是：

  1. 使用每个请求重新解析主机名以在所有 ELB ip 之间分配负载，尤其是在添加新的 IP 以响应增加的流量时。
  2. 非常缓慢地增加负载测试。亚马逊建议每 5 分钟最多将 ELB 的负载增加 50%。

如果单个 ELB 节点上允许的并发连接方面的 HTTP/HTTPS 容量之间的差异很大，我并不感到特别惊讶，如果您固定到一个 IP，这可能是您观察到的差异的原因。

我不知道 https://*.herokuapp.com 堆栈的详细信息，但我一点也不惊讶它可以提供比冷 ssl:endpoint ELB 更多的 https 流量。

于 2013-07-20T04:42:31.583 回答