我目前在 Heroku 上托管了一个 ruby on rails 应用程序，我正在使用 New Relic 进行监控。我的应用程序在使用时有些滞后，我的 New Relic 监视器显示以下内容：
鉴于大部分时间都花在请求队列上，这是否意味着如果我使用额外的工作人员测功机，我的应用程序会更好地扩展？或者这是我可以通过优化我的代码来解决的问题？对不起，如果这是一个愚蠢的问题，但我是一个完全的新手，感谢所有的帮助。谢谢！
== 编辑 ==
只是想确保我在不得不支付额外的 moolah 之前对此非常清楚。所以New Relic还给了我浏览器端的以下统计数据，你可以在这里看到：
此图显示用户花费的大部分时间都在等待 Web 应用程序。我可以将此归因于我的应用程序大部分时间都在请求队列中吗？换句话说，最终用户体验到的 1.3 秒响应时间目前仅靠代码优化几乎无法减少？（基本上我在问我是否必须花钱）谢谢！
请求队列基本上意味着“等待 Web 实例可用于处理请求”。
因此，在响应时间上获得一些速度的最简单和最快的方法是增加 Web 实例的数量，以允许您的应用程序更快地处理更多请求。
优化您的代码以将每个单独的请求加速到您的应用程序每分钟可以处理更多请求的速度可能是可能的——这将更快地将请求从队列中拉出并减少整体请求排队问题。
随着时间的推移，尽一切可能优化代码仍然是一个好主意。但首先，添加更多工作人员，您的请求排队问题很可能会减少或消失。
编辑
有了你的额外信息，总的来说，我相信故事还是一样的——尽管在花钱之前深入了解是件好事。
当您有请求排队时，这是因为请求正在等待Web 实例可以为他们的请求提供服务。添加更多 Web 实例会通过使更多实例可用来直接影响这一点。
您可以很好地优化应用程序，从而显着减少处理每个请求的时间。如果发生这种情况，那么它也会通过让请求等待更短的时间来获得服务来减少请求排队。
我建议现在为用户提供更多Web 实例以立即解决排队问题，然后尽可能优化代码（假设这是您的首要任务）。而且，无论您的应用程序响应速度有多快，如果您的用户增长，您将需要实施更多的 Web 实例来跟上 - 顺便说一句，这是一个很好的问题，因为您的用户也在增长。
祝你好运！
我只是想把这个扔进去，即使这个特定的问题似乎已经回答了。我从 New Relic 和 Engine Yard 的人那里找到了这篇博文：博文。
这里的tl;dr是 New Relic 中的请求排队不一定是请求实际上在队列中排队并且无法得到处理。由于 New Relic 是如何计算这个指标的，它本质上是读取 nginx 在标头中设置的时间戳，并从Time.nowNew Relic 方法获取它时减去它。然而，New Relic 会在你的代码的任何钩子被调用后运行。before_filter因此，如果您在这些before_filters 中运行大量计算密集型或数据库密集型代码，那么您看到的可能实际上是请求延迟，而不是排队。
您实际上可以检查队列以查看其中的内容。如果您使用Passenger，这真的很简单——只需passenger status在命令行上输入。这将向您显示有关每个乘客工作人员的大量信息，包括队列中的请求数量。如果您使用前面的 with 运行watch，该命令将每 2 秒执行一次，因此您可以看到队列如何随时间变化（因此只需执行watch passenger status）。
对于 Unicorn 服务器，这有点困难，但有一个可以运行的 ruby 脚本，可在此处获得。该脚本实际上检查了独角兽套接字中有多少请求等待工作人员接收。因为它正在检查套接字本身，所以运行此命令的频率不应超过 ~3 秒左右。GitHub 上的示例使用 10。
如果您看到大量排队请求，那么添加水平扩展（通过 Heroku 上的更多 Web 工作者）可能是一个合适的措施。但是，如果队列很低，但 New Relic 报告请求队列很高，那么您实际上看到的是请求延迟，您应该检查您before_filter的 s，或者将它们的范围仅限于那些绝对需要它们的方法，或者继续工作优化那些过滤器正在执行的代码。
我希望这对以后来这个线程的人有所帮助！