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