Heroku：Web dyno与worker dyno？我需要多少比例？

我很好奇Heroku上的网络和工人dynos之间的区别。他们在定价页面上给出了一句话的解释，但这让我感到困惑。我怎么知道每个选择几只？我应该追求一个比例吗？我对这些东西还很陌生，所以有人可以详细解释一下，或者我可以通过某种方式计算出我需要多少种测功机？

另外，对于每个测功的小时数，我感到困惑。

http://www.heroku.com/pricing

我也碰到了这篇文章。作为建议的解决方案之一，他们说增加测功机的数量。他们在这里指的是哪种测功机？

http://devcenter.heroku.com/articles/backlog-too-deep

如果您需要更多的测功机（Cedar上的aka进程），则最好的指示就是您的heroku日志。确保升级到扩展日志记录（免费），以便可以拖尾日志。

您正在寻找heroku.router条目，而您最感兴趣的值是队列值-如果该值始终大于0，那么这是一个好兆头，您需要添加更多的dynos。从本质上讲，这意味着传入的请求将超过您的进程所能处理的数量，因此它们正在排队。如果它们排队太长时间而没有返回任何数据，则它们将超时。

恐怕没有理想的比率，您可能有一个应用程序每秒执行100个请求，而这需要许多Web流程，但是却没有使用任何工作程序。仅当您在后台进行处理（例如发送电子邮件等）时，才需要工作进程。

ps积压太深的Dyno Web进程将导致它。

更新：2013年3月26日，Heroku从注销日志中删除了队列和等待字段。

队列和等待字段已从路由器日志消息中删除。而且，Heroku路由器不再为传入请求设置X-Heroku-Dynos使用中，X-Heroku-队列深度和X-Heroku-队列等待时间HTTP标头。

Dynos基本上是在您的实例上运行的进程。使用新的Cedar堆栈，可以将它们设置为执行任何任意的shell命令。对于Web应用程序，通常有一个名为“ web”的进程，该进程负责响应用户的HTTP请求。所有其他过程以前称为“工人”。这些程序在后台连续运行，以进行cron，处理队列以及您不想占用Web进程的大量计算。您还可以扩展每种类型的进程，以便启动每种类型的多个进程以实现更多的并发性。每种类型的使用量实际上取决于应用程序的需求及其所承受的负载。您可以使用New Relic插件之类的工具来监视这些事情。

许多人提到，尚无已知比率，您将要使用的网络工作者与“背景”工作者的比率取决于设计应用程序的方式-正确。但是，我认为添加一条作为一般经验法则可能很有用，您希望您的Web工作者-从而他们服务的控制器行为-快速而轻巧，以减少浏览器行为的响应时间延迟。如果某些浏览器动作需要大约超过半秒的实时时间才能提供服务，那么您可能会希望构建某种系统，以将该动作的大部分推入队列。

然后，您将设计一个将为该队列提供服务的脱机工作人员dyno。它们可能需要更长的时间，因为它们的输出中没有待处理的HTTP响应。也许您从初始浏览器请求中呈现的，推动该操作的页面将提供一些Javascript，该Javascript启动一个线程，该线程检查请求是否每5秒完成一次，或者类似情况。

由于其他人给出的相同原因，我仍然无法给您一个合适的比例，但是希望这可以帮助您决定如何设计应用程序。（我还要指出，这只是许多有效设计中的一种。）

https://stackoverflow.com/a/19965981/1233555-Heroku进行了随机路由，因此某些dynos可以将队列堆积起来（它们为冗长的请求提供服务），而其他dynos是免费的。通过确保在Web dynos中非常快速地处理所有请求来避免这种情况。这将减少您需要的网络测功机的数量，同时需要更多的工人测功机。

您还需要关心Web应用程序支持的并发性，只有某些Rails配置才能做到这一点-尝试使用Unicorn或使用Thin精心编写的代码（对于不阻塞EventMachine的I / O）。

您可能必须尝试而不是计算，才能查看所需的每种类型的测功机。确保他们的New Relic报告了dyno队列-请参阅上面的链接。

简短的答案是，您需要尽可能多的队列来减少队列。

如John所述，如果您开始在日志中看到队列，则需要更多的测功机。如果您开始发现后台队列过长（获取此信息的方式取决于您实施的方式），那么您需要更多的工作人员。

没有比率，因为它很大程度上取决于您的应用程序设计和使用情况。