使用Heroku扩展Dynos

Question

我目前在Heroku托管的rails应用程序上有一个ruby，我正在使用New Relic进行监控。使用它时我的应用程序有点滞后，我的New Relic监视器向我显示以下内容：

鉴于大部分时间花在请求排队上，这是否意味着如果我使用额外的工作人员dynos，我的应用程序会扩展得更好？或者这是我可以通过优化我的代码来解决的问题？对不起，如果这是一个愚蠢的问题，但我是一个完整的新手，并感谢所有的帮助。谢谢！

==编辑==

只是想确保我在此之前清楚地说明了这一点，然后再打包出更多的moolah。所以New Relic还在浏览器方面给了我以下统计数据，如下所示：

此图表显示用户花费的大部分时间都在等待Web应用程序。我可以将此归因于我的应用程序将大部分时间花在请求队列中吗？换句话说，最终用户正在经历的1.3秒响应时间目前只有代码优化才能减少？ （基本上我问我是否要花钱）谢谢！

Answer 1

请求排队基本上意味着“等待Web实例可用于处理请求”。

因此，在响应时间内获得一些速度的最简单，最快捷的方法是增加Web实例的数量，以便让您的应用更快地处理更多请求。

优化代码可能是可行的，可以将每个请求加速到应用程序每分钟处理更多请求的程度 - 这样可以更快地将请求从队列中拉出来，并减少整个请求排队问题。

随着时间的推移，尽一切可能优化代码仍然是个好主意。但首先，添加更多工作人员，您的请求排队问题很可能会减少或消失。

修改

通过您的其他信息，一般来说，我相信这个故事仍然是相同的 - 尽管在花钱之前需要深入了解。

1. 当您有请求排队时，因为请求正在等待 Web实例可用于为其请求提供服务。通过提供更多实例，可以直接添加更多Web实例。

2. 您可以优化应用程序，以便大大减少处理每个请求的时间。如果发生这种情况，那么它将减少请求排队，同时使请求等待更短的时间进行服务。

我建议现在为用户提供更多 Web实例，以便立即解决排队问题，然后尽可能地优化代码（假设这是您的最大优先级）。无论您的应用程序响应速度有多快，如果您的用户增长，您需要实施更多的Web实例以保持同步 - 这也是一个很好的问题，因为您的用户也在增长。

祝你好运！

Answer 2

我只是想把它扔进去，即使这个特殊的问题似乎得到了回答。我在New Relic和Engine Yard的那些人发现了这篇博文：Blog Post。

这里的 tl; dr 是New Relic中的请求队列不是必然请求实际排队在队列中而无法得到处理。由于New Relic如何计算此度量标准，它实际上会读取nginx在标头中设置的时间戳，并在New Relic方法获取它时从Time.now中减去它。但是，在任何代码的before_filter挂钩被调用之后，New Relic会运行。因此，如果您在这些before_filter中运行了大量计算密集型或数据库密集型代码，那么您可能看到的实际上是请求延迟，而不是排队。

您实际上可以检查队列以查看其中的内容。如果您正在使用Passenger，这非常简单 - 只需在命令行上键入passenger status即可。这将向您显示有关每个乘客工作人员的大量信息，包括排队的请求数量。如果以watch开头运行，该命令将每2秒执行一次，这样您就可以看到队列随时间的变化（所以只需执行watch passenger status）。

对于Unicorn服务器来说，它有点困难，但是你可以运行一个ruby脚本，可用here。该脚本实际上检查了多少请求位于独角兽插槽中，等待工作人员接收。因为它正在检查套接字本身，所以你不应该经常运行这个命令大约3秒左右。 GitHub上的示例使用10。

如果您看到大量排队请求，那么添加水平扩展（通过Heroku上的更多Web工作者）可能是一个合适的衡量标准。但是，如果队列很低，但New Relic报告了高请求排队，那么您实际看到的是请求延迟，您应该检查before_filter，并将它们范围限定为只有那些方法绝对需要它们，或者优化那些过滤器正在执行的代码。

我希望这有助于将来有人来到这个主题！