Heroku dynos/workers 的性能如何？
拥有 1 或 2 个 Dyno 的网站可以在 www.Heroku.com 上处理多少流量，增加工作人员是否会改善这一情况？对测功机/工人的任何帮助将不胜感激。
How much traffic can a site with 1 or 2 Dynos handle on www.Heroku.com and would increasing workers improve this? Any help on dynos/workers would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
此博客条目可能有用。他对 Heroku 可能遇到的瓶颈类型以及增加 dynos 如何提供帮助进行了详细分析，并提供了 heroku 的官方性能指南以及一些可帮助您测试自己的应用程序的工具。
工作人员的表现实际上取决于您的站点的构建方式以及您使用它们的目的。称为延迟作业的后台处理（图像格式化、帐户修剪等）是您放置它们的方式工作
编辑 // 2012 年 3 月 1 日：
这是另一篇博客文章，探讨了 Heroku 延迟和吞吐量性能对于可变数量的 Dynos。
编辑 // 2013 年 2 月 28 日：
在这篇文章中提出关于 Heroku 的随机路由算法和扩展 Dynos 时指标（特别是 New Relic 提供的指标）可能会被误报。这仍然是一个持续存在的问题，在我之前的回答中需要注意。 Heroku 的回复在帖子内有链接。
编辑 // 2013 年 5 月 8 日：
最近在 Shelly Cloud 博客上发布的帖子分析所使用的测功机和 Web 服务器数量对应用程序性能的影响。那里使用的基线性能脚本应该对执行进一步的测试有用。
This blog entry may be of use. He does a great breakdown of the kind of bottlenecks heroku can run into, and how increasing dynos can help, and provides links and information to the official performance guide on heroku as well as some tools that will help you test your own app.
Worker performance really depends on how your site is built and what you are using them for. Background processing (image formatting, account pruning, etc) called Delayed Jobs is how you put them to work
EDIT // 1 March 2012:
Here is another blog entry that explored heroku latency and throughput performance for a variable number Dynos.
EDIT // 28 Feb 2013:
There have been some concerns raised in this post regarding Heroku's random routing algorithm and how metrics may be misreported when scaling Dynos, specifically those provided by New Relic. This is still an ongoing issue and is something to note in the context of my previous answer. Heroku's responses are linked within the post.
EDIT // 8 May 2013:
A recent post on Shelly Cloud blog analyses impact of number of dynos and web server used on application perfomance. Baseline performance script used there should be useful in performing further tests.
测试它的一个好方法是使用 Apache Bench 工具。您的计算机上可能已经安装了它。首先检查一下（unix / os x）：
AB文档和安装说明：http:// /httpd.apache.org/docs/2.0/programs/ab.html
安装后，尝试向您的 Heroku 站点发送一些流量。
其中 N 是发出的请求总数，C 是允许的并发请求数。 Uping C 似乎给了我最失败的回应。
请记住，Heroku 实例在 Varnish 后面运行，因此您可能正在测试 Varnish 缓存，而不是 Ruby。检查您的应用程序发送的“缓存控制”标头。
A good way of testing it is using the Apache Bench tool. You may already have it installed on your computer. Check it first (unix / os x):
AB documentation and installation instructions: http://httpd.apache.org/docs/2.0/programs/ab.html
Once installed, try sending some traffic to your Heroku site.
Where N is the total number of requests to make, and C is the number of concurrent requests to allow. Upping C seems to give me the most failed responses.
Remember that an Heroku instance runs behind Varnish, so you may be testing the Varnish cache, not Ruby. Check what 'cache-control' headers your app is sending.
我还建议安装 New Relic 附加组件。它可以让您进行基本的性能监控并帮助识别瓶颈。
I would also suggest installing the New Relic Add-on. It lets you do basic performance monitoring and helps identify bottlenecks.