使用Heroku縮放Dynos

Question

我目前在Heroku上託管的應用程序上有一個紅寶石，我使用New Relic進行監視。使用它時我的應用程序是有點laggy，和我的New Relic的監視器顯示我以下：

鑑於大部分時間都在請求隊列中度過的，這是否意味着，如果我在我的應用程序將變得更好使用額外的工人dynos？或者這是我可以通過優化我的代碼來修復的東西？對不起，如果這是一個愚蠢的問題，但我是一個完整的新手，並感謝所有的幫助。謝謝！

== ==編輯

只是想確保我是水晶明確這一點，不得不掏出更多的之前的Moolah。因此，New Relic的也給了我下面的統計數據在瀏覽器端，你可以在這裏看到：

該圖顯示，大多數的用戶所花的時間是在等待Web應用程序。我可以將這歸因於我的應用程序大部分時間都在請求隊列中嗎？換句話說，最終用戶正在經歷的1.3秒響應時間目前僅僅是代碼優化對於減少的影響不大。 （基本上我問我是否需要花錢）謝謝！

Answer 1

請求隊列基本上意味着'等待web實例可用於處理請求'。

因此，獲得響應時間一些速度的最簡單和最快的方法是增加Web實例的數量，以使您的應用程序能夠更快地處理更多請求。

優化您的代碼以加速每個單獨請求到您的應用程序可以每分鐘處理更多請求的點 - 這可以更快地將請求從隊列中拉出並減少總體請求排隊問題。

不管怎樣，儘管如此，儘可能地優化代碼仍然是一個不錯的主意。但首先，增加更多的工作人員，並且您的請求排隊問題可能會減少或消失。

編輯

你更多的信息，總的來說，我相信這個故事仍然是相同的 - 雖然在得到一個深刻的理解花錢之前不錯的工作。

1. 當你請求排隊，那是因爲請求正在等待web實例變得可用來服務他們的請求。直接添加更多Web實例通過提供更多實例來影響這一點。

2. 您可以優化應用程序以便顯着縮短處理每個請求的時間。如果發生這種情況，那麼通過使請求等待更短的時間來服務，它也會減少請求排隊。

我推薦給用戶帶來更多web實例現在立即解決排隊問題，然後儘可能多的，你可以對代碼進行優化工作（假設這是你最大的優先級）。無論您的應用程序響應速度有多快，如果您的用戶數量不斷增加，您需要實施更多網絡實例才能跟上 - 順便說一句，由於您的用戶也在增長，這也是一個很好的問題。

祝你好運！

Answer 2

我只是想扔這個，即使這個問題似乎回答。我發現了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，而其中任何範圍，只有那些絕對需要它們的方法，或工作優化那些過濾器正在執行的代碼。

我希望這可以幫助任何人來到這個線程在未來！