用Heroku缩放Dynos [英] Scaling Dynos with Heroku

问题描述

我目前在Heroku上托管的应用程序上有一个红宝石，我正在使用New Relic进行监控。我的应用程序在使用时有些迟钝，我的New Relic监视器向我显示了以下内容：

==编辑==

只是想确保我在此之前清楚地了解掏出额外的药水。所以New Relic也给了我浏览器端的以下统计数据，你可以在这里看到：

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

解决方案

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

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

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

到时候，它仍然是一个好主意尽你所能去优化代码。但首先，增加更多的工作人员，并且您的请求排队问题可能会减少或消失。

编辑

以及额外的信息，但总的来说，我相信这个故事仍然是一样的 - 尽管在花钱之前深入理解这件事很好。

1. 请求排队时，这是因为请求正在等待 web实例变为可用来为其请求提供服务。直接添加更多Web实例会影响到这一点，因为可以提供更多实例。

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

现在我建议为用户提供更多的 web实例，以便立即解决排队问题问题，然后尽可能地优化代码（假设这是您的最大优先事项）。无论您的应用程序响应速度有多快，如果您的用户数量不断增加，您需要实施更多网络实例才能跟上 - 顺便说一句，由于您的用户也在增长，这也是一个很好的问题。

祝你好运！

I've currently got a ruby on rails app hosted on Heroku that I'm monitoring with New Relic. My app is somewhat laggy when using it, and my New Relic monitor shows me the following:

Given that majority of the time is spent in Request Queuing, does this mean my app would scale better if I used an extra worker dynos? Or is this something that I can fix by optimizing my code? Sorry if this is a silly question, but I'm a complete newbie, and appreciate all the help. Thanks!

== EDIT ==

Just wanted to make sure I was crystal clear on this before having to shell out additional moolah. So New Relic also gave me the following statistics on the browser side as you can see here:

This graph shows that majority of the time spent by the user is in waiting for the web application. Can I attribute this to the fact that my app is spending majority of its time in a requesting queue? In other words that the 1.3 second response time that the end user is experiencing is currently something that code optimization alone will do little to cut down? (Basically I'm asking if I have to spend money or not) Thanks!

解决方案

Request Queueing basically means 'waiting for a web instance to be available to process a request'.

So the easiest and fastest way to gain some speed in response time would be to increase the number of web instances to allow your app to process more requests faster.

It might be posible to optimize your code to speed up each individual request to the point where your application can process more requests per minute -- which would pull requests off the queue faster and reduce the overall request queueing problem.

In time, it would still be a good idea to do everything you can to optimize the code anyway. But to begin with, add more workers and your request queueing issue will more than likely be reduced or disappear.

edit

with your additional information, in general I believe the story is still the same -- though nice work in getting to a deep understanding prior to spending the money.

1. When you have request queuing it's because requests are waiting for web instances to become available to service their request. Adding more web instances directly impacts this by making more instances available.

2. It's possible that you could optimize the app so well that you significantly reduce the time to process each request. If this happened, then it would reduce request queueing as well by making requests wait a shorter period of time to be serviced.

I'd recommend giving users more web instances for now to immediately address the queueing problem, then working on optimizing the code as much as you can (assuming it's your biggest priority). And regardless of how fast you get your app to respond, if your users grow you'll need to implement more web instances to keep up -- which by the way is a good problem since your users are growing too.

Best of luck!

这篇关于用Heroku缩放Dynos的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！