2012-06-29 142 views
2

我目前在Heroku上托管的应用程序上有一个红宝石,我使用New Relic进行监视。使用它时我的应用程序是有点laggy,和我的New Relic的监视器显示我以下:使用Heroku缩放Dynos

NewRelicGraph

鉴于大部分时间都在请求队列中度过的,这是否意味着,如果我在我的应用程序将变得更好使用额外的工人dynos?或者这是我可以通过优化我的代码来修复的东西?对不起,如果这是一个愚蠢的问题,但我是一个完整的新手,并感谢所有的帮助。谢谢!

== ==编辑

只是想确保我是水晶明确这一点,不得不掏出更多的之前的Moolah。因此,New Relic的也给了我下面的统计数据在浏览器端,你可以在这里看到:

NewRelicBrowserGraph

该图显示,大多数的用户所花的时间是在等待Web应用程序。我可以将这归因于我的应用程序大部分时间都在请求队列中吗?换句话说,最终用户正在经历的1.3秒响应时间目前仅仅是代码优化对于减少的影响不大。 (基本上我问我是否需要花钱)谢谢!

回答

3

请求队列基本上意味着'等待web实例可用于处理请求'。

因此,获得响应时间一些速度的最简单和最快的方法是增加Web实例的数量,以使您的应用程序能够更快地处理更多请求。

优化您的代码以加速每个单独请求到您的应用程序可以每分钟处理更多请求的点 - 这可以更快地将请求从队列中拉出并减少总体请求排队问题。

不管怎样,尽管如此,尽可能地优化代码仍然是一个不错的主意。但首先,增加更多的工作人员,并且您的请求排队问题可能会减少或消失。

编辑

你更多的信息,总的来说,我相信这个故事仍然是相同的 - 虽然在得到一个深刻的理解花钱之前不错的工作。

  1. 当你请求排队,那是因为请求正在等待web实例变得可用来服务他们的请求。直接添加更多Web实例通过提供更多实例来影响这一点。

  2. 您可以优化应用程序以便显着缩短处理每个请求的时间。如果发生这种情况,那么通过使请求等待更短的时间来服务,它也会减少请求排队。

我推荐给用户带来更多web实例现在立即解决排队问题,然后尽可能多的,你可以对代码进行优化工作(假设这是你最大的优先级)。无论您的应用程序响应速度有多快,如果您的用户数量不断增加,您需要实施更多网络实例才能跟上 - 顺便说一句,由于您的用户也在增长,这也是一个很好的问题。

祝你好运!

+0

只是要确保我得到你,你的答案是“是添加另一名工人DYNOS”? – oort

+0

是的 - 这是加快速度的最快方法。 –

+0

检查我的编辑 - –

1

我只是想扔这个,即使这个问题似乎回答。我发现了New Relic的这篇博客文章,以及Engine Yard上的那些人:Blog Post

TL;这里博士是请求在New Relic的排队,其实并不是一定请求在队列中排队和不能够得到处理。由于New Relic如何计算这个度量标准,它实质上是读取一个由nginx设置在标题中的时间戳,并在New Relic方法获得它时从Time.now中减去它。然而,新的文物被后运行任何代码的before_filter钩子被调用。因此,如果您在这些before_filter s中运行了大量计算密集型或数据库密集型代码,则可能您所看到的实际上是请求延迟,而不是排队。

您实际上可以检查队列以查看内容。如果您使用Passenger,这非常简单 - 只需在命令行输入passenger status即可。这将向您显示关于您的每位乘客的大量信息,包括有多少请求在队列中。如果在watch之前运行该命令,则该命令将每2秒执行一次,以便您可以看到队列随着时间如何变化(因此只需执行watch passenger status)。

对于独角兽服务器来说,这有些困难,但有一个ruby脚本可以运行,可用here。这个脚本实际上检查了独角兽插座中有多少个请求,正在等待被工作人员拾取。因为它正在检查套接字本身,所以不应该比〜3秒左右更频繁地运行此命令。 GitHub上的示例使用10.

如果您看到大量排队的请求,那么添加水平缩放(通过Heroku上的更多Web工作人员)可能是一种适当的度量。然而,如果队列为低,但New Relic的报告要求高排队,你实际上看到的是请求的延迟,你应该检查你的before_filter s,而其中任何范围,只有那些绝对需要它们的方法,或工作优化那些过滤器正在执行的代码。

我希望这可以帮助任何人来到这个线程在未来!