基于Blitz.io的Heroku SSL瓶颈分析

Question

我有一个简单的Django应用程序设置，我已经用Blitz.io测试过了。当我使用许多dynos进行测试时，我可以在http:// X.com上获得数以千计的请求/秒当我切换到https:// X.com时，我得到的请求/秒不超过72Req/s，无论有多少个dynos。在https:// X.herokuapp.com/上，我得到了更多，但它仍然达到了几百个请求/秒的峰值。

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

Answer 1

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

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

Answer 2

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

使用AWS弹性负载均衡器实现ssl:endpoint插件。ELB使用DNS在它们的节点之间分配负载。根据我的经验，每个ELB节点都不是特别健壮，从CPU的角度来看，SSL协商/解密也不是微不足道的。因此，在进行负载测试时，重要的是：

1. 在每次请求时都会重新解析主机名，以便在所有ELB之间分配负载，特别是在添加新的up以响应增加的流量时。
2. 使您的负载测试速度非常慢。亚马逊建议ELB每5分钟最多增加50%的负载。

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

我不知道https://*.herokuapp.com堆栈的细节，但我一点也不惊讶于它可以服务于比冷ssl:端点ELB更多的https流量。