我很好奇网上和 Worker dynos在Heroku上有什么区别 . 他们在定价页面上给出了一句话的解释，但这让我感到困惑 . 我怎么知道每个挑选多少？我应该瞄准的比例是多少？我对这些东西很陌生，所以有人可以给出一个深入的解释，或者某种方式我可以计算出我需要多少和哪种dynos？
另外，我对每个dyno的小时数的含义感到困惑 .
http://www.heroku.com/pricing
我也发生在这篇文章上 . 作为他们建议的解决方案之一，他们说要增加动力学的数量 . 他们指的是哪种类型的dyno？
http://devcenter.heroku.com/articles/backlog-too-deep
如果你需要更多dynos（也就是Cedar上的进程），你最好的指示是你的heroku日志 . 确保升级到扩展日志记录（它是免费的），以便您可以拖尾日志 .
你正在寻找heroku.router条目，你最感兴趣的值是队列值 - 如果这个值一直大于0，那么你需要添加更多的dynos是个好兆头 . 从本质上讲，这意味着有更多的请求进入，而不是您的进程可以处理，因此它们正在排队 . 如果他们排队太长而没有返回任何数据，他们将超时 .
我担心没有理想的比例，你可以让一个应用程序每秒执行100个请求需要很多Web进程，但只是没有使用工作者 . 如果您在后台进行处理，如发送电子邮件等，则只需要工作进程等 .
ps积压太深将是一个导致它的Dyno Web进程 .
更新：2013年3月26日，Heroku从注销中删除了队列和等待字段 .
队列和等待字段已从路由器日志消息中删除 . 此外，Heroku路由器不再为传入请求设置X-Heroku-Dynos-In-Use，X-Heroku-Queue-Depth和X-Heroku-Queue-Wait-Time HTTP标头 .
Dynos基本上是在您的实例上运行的进程 . 使用新的Cedar堆栈，可以将它们设置为执行任何任意shell命令 . 对于Web应用程序，通常有一个名为“web”的进程负责响应来自用户的HTTP请求 . 所有其他流程都是以前称为“ Worker ”的流程 . 这些内容在后台持续运行，例如cron，处理队列以及任何您不希望绑定Web进程的繁重计算 . 您还可以扩展每种类型的进程，以便引导每种类型的多个进程以获得额外的并发性 . 您使用的每个数量实际上取决于您的应用程序的需求和它收到的负载 . 您可以使用New Relic插件等工具来监控这些事情 . 有关详细信息，请查看Heroku开发中心的Process Model和Procfile上的文章 .
很多人都提到没有已知的比例，你想要的网络工作者与 Worker 的比例取决于你设计应用程序的方式 - 这是正确的 . 但是我认为添加它作为一般经验法则可能是有用的，您希望您的Web工作人员 - 以及他们所服务的控制器操作 - 快速且非常轻量级，以减少浏览器操作的响应时间延迟 . 如果某些浏览器操作需要超过，比如大约半秒的实时服务时间，那么您可能希望构建某种将该操作的大部分推送到队列的系统 .
然后，您将设计一个将为此队列提供服务的脱机工作器dyno . 它们可能需要更长的时间，因为它们的输出上没有待处理的HTTP响应 . 也许您从推送操作的初始浏览器请求呈现的页面将提供一些启动线程的Javascript，该线程检查请求是否每5秒完成一次，或者沿着这些线路完成 .
由于其他人给出的相同原因，我仍然无法给你一个合作比例，但希望这有助于你决定如何构建你的应用程序 . （我还应该提到这只是许多有效设计中的一种设计 . ）
https://stackoverflow.com/a/19965981/1233555 - Heroku已经进入随机路由，因此一些dynos可以堆叠队列（当他们提供冗长的请求时），而其他dynos是免费的 . 通过确保在Web dynos中快速处理所有请求来避免这种情况 . 这将减少您需要的网络动态数量需要更多的 Worker 动力 .
您还需要关心支持并发的Web应用程序，只有一些Rails配置可以做 - 尝试Unicorn，或者使用Thin精心编写的代码（对于不阻止EventMachine的I / O） .
您可能需要尝试而不是计算，以查看您需要的每种类型的dynos . 确保他们的New Relic报告dyno队列 - 请参阅上面的链接 .
简短的回答是，您需要尽可能多的人来保持排队 .
正如John所描述的，如果你开始在日志中看到一个队列，那么你需要更多的dynos . 如果您开始看到后台队列变得太长（如何获得此信息取决于您实施的内容）那么您需要更多的工作人员 .
没有比例，因为它非常依赖于您的应用程序设计和使用 .
5 回答
如果你需要更多dynos（也就是Cedar上的进程），你最好的指示是你的heroku日志 . 确保升级到扩展日志记录（它是免费的），以便您可以拖尾日志 .
你正在寻找heroku.router条目，你最感兴趣的值是队列值 - 如果这个值一直大于0，那么你需要添加更多的dynos是个好兆头 . 从本质上讲，这意味着有更多的请求进入，而不是您的进程可以处理，因此它们正在排队 . 如果他们排队太长而没有返回任何数据，他们将超时 .
我担心没有理想的比例，你可以让一个应用程序每秒执行100个请求需要很多Web进程，但只是没有使用工作者 . 如果您在后台进行处理，如发送电子邮件等，则只需要工作进程等 .
ps积压太深将是一个导致它的Dyno Web进程 .
更新：2013年3月26日，Heroku从注销中删除了队列和等待字段 .
Dynos基本上是在您的实例上运行的进程 . 使用新的Cedar堆栈，可以将它们设置为执行任何任意shell命令 . 对于Web应用程序，通常有一个名为“web”的进程负责响应来自用户的HTTP请求 . 所有其他流程都是以前称为“ Worker ”的流程 . 这些内容在后台持续运行，例如cron，处理队列以及任何您不希望绑定Web进程的繁重计算 . 您还可以扩展每种类型的进程，以便引导每种类型的多个进程以获得额外的并发性 . 您使用的每个数量实际上取决于您的应用程序的需求和它收到的负载 . 您可以使用New Relic插件等工具来监控这些事情 . 有关详细信息，请查看Heroku开发中心的Process Model和Procfile上的文章 .
很多人都提到没有已知的比例，你想要的网络工作者与 Worker 的比例取决于你设计应用程序的方式 - 这是正确的 . 但是我认为添加它作为一般经验法则可能是有用的，您希望您的Web工作人员 - 以及他们所服务的控制器操作 - 快速且非常轻量级，以减少浏览器操作的响应时间延迟 . 如果某些浏览器操作需要超过，比如大约半秒的实时服务时间，那么您可能希望构建某种将该操作的大部分推送到队列的系统 .
然后，您将设计一个将为此队列提供服务的脱机工作器dyno . 它们可能需要更长的时间，因为它们的输出上没有待处理的HTTP响应 . 也许您从推送操作的初始浏览器请求呈现的页面将提供一些启动线程的Javascript，该线程检查请求是否每5秒完成一次，或者沿着这些线路完成 .
由于其他人给出的相同原因，我仍然无法给你一个合作比例，但希望这有助于你决定如何构建你的应用程序 . （我还应该提到这只是许多有效设计中的一种设计 . ）
https://stackoverflow.com/a/19965981/1233555 - Heroku已经进入随机路由，因此一些dynos可以堆叠队列（当他们提供冗长的请求时），而其他dynos是免费的 . 通过确保在Web dynos中快速处理所有请求来避免这种情况 . 这将减少您需要的网络动态数量需要更多的 Worker 动力 .
您还需要关心支持并发的Web应用程序，只有一些Rails配置可以做 - 尝试Unicorn，或者使用Thin精心编写的代码（对于不阻止EventMachine的I / O） .
您可能需要尝试而不是计算，以查看您需要的每种类型的dynos . 确保他们的New Relic报告dyno队列 - 请参阅上面的链接 .
简短的回答是，您需要尽可能多的人来保持排队 .
正如John所描述的，如果你开始在日志中看到一个队列，那么你需要更多的dynos . 如果您开始看到后台队列变得太长（如何获得此信息取决于您实施的内容）那么您需要更多的工作人员 .
没有比例，因为它非常依赖于您的应用程序设计和使用 .