Heroku根据Blitz.io的瓶颈

Question

我有一个简单的Django应用程序设置，我一直在测试Blitz.io。 当我用很多dynos测试时，我可以在http：// X.com 上获得数以千计的req/s当我切换到https：// X.com时，无论有多少个dynos，我都得到不超过72个req/s。 而在https：// X.herokuapp.com/上，我获得了更多，但仍然达到了几百个请求/秒。

这是一个侥幸，不会出现正常使用情况？闪电战的问题？ Heroku问题？资源是否会随需求扩大？

Answer 1

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

ssl：endpoint插件是使用AWS Elastic Load Balancer实现的。 ELB使用DNS在其节点之间分配负载。根据我的经验，每个单独的ELB节点并不特别健壮，从CPU的角度来看，SSL协商/解密并非微不足道。

1. 与每个请求重新解析主机名来分配负载在所有的ELB IPS，特别是随着新的响应流量增加补充说：所以，当负载测试是非常重要的。
2. 非常缓慢地加载负载测试。亚马逊建议每5分钟最多增加50％的ELB负荷。

我不是特别惊讶，如果允许一个单一的ELB节点上的并发连接方面HTTP/HTTPS容量之间的差别是巨大的，而如果你是固定一个IP，可以考虑区别吗正在观察。

我不知道https：//*.herokuapp.com堆栈的详细信息，但我并不感到惊讶，它可以提供比SSL ssl：端点ELB更多的https流量。

Answer 2

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

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