Heroku |如何閱讀路由器日誌

所以在雪松平臺長相我典型的路由器日誌可能看起來像Heroku |如何閱讀路由器日誌

2012-03-22T18:26:34+00:00 heroku[router]: GET [my_url] dyno=web.9 queue=0 wait=0ms service=228ms status=302 bytes=212 
2012-03-22T18:26:36+00:00 heroku[router]: GET [my_url] dyno=web.7 queue=0 wait=0ms service=23ms status=200 bytes=360 
2012-03-22T18:26:45+00:00 heroku[router]: GET [my_url] dyno=web.30 queue=0 wait=0ms service=348ms status=201 bytes=1

我想確認我的條款queue，wait和service

我最初的想法的理解其中：

隊列：隊列的名稱if使用background_job或resque
等待：多久請求路由器等（請在New Relic的隊列）
服務：它實際上需要多長時間你的應用程序來處理請求（不包括queing時間）

但我等待在我的日誌是總是 0毫秒。即使我有重要的積壓。

我的定義是否錯誤？

來源

2012-03-22 Jonathan

你說你的等待時間總是0ms，如果隊列也是0，你怎麼知道你在這之外有積壓？ – 2012-03-22 19:19:22

因此，例如，服務我的crossdomain.xml - 一個靜態文件，在10ms內低負載響應。在高負載情況下，可以達到6000ms +直到30秒超時。我期望大部分時間都在排隊等待。 – Jonathan 2012-03-22 19:55:09

另外，當我添加更多的dynos時，服務時間會下降，反之亦然 – Jonathan 2012-03-22 20:05:52

隊列：等待由測功機處理的請求數。
等待：此請求在處理之前處於隊列中的時間長度。
服務：請求的處理時間。

您的總響應時間將是等待+服務。

來源

2012-03-22 19:18:31

您能否更詳細地解釋「服務」的含義？這是否意味着，在發送響應之前需要通過任何腳本運行的時間，還是一些內部計時器與代碼沒有任何關係？ – 2012-07-17 16:24:34

「在發送回覆之前運行任何腳本所花的時間」 - 這個。 – 2012-07-25 09:50:27

作爲一個警告，「服務」時間似乎考慮到網絡時間。這很可能類似於IIS日誌中的「花費時間」。 http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb.mspx?mfr=true 我基於此比較一些長期運行的項目（〜 20+秒），並與新文物的「實際用戶監測」進行比較，表明將近100％的時間爲「網絡」時間。 – Jody 2012-10-04 16:58:07

Heroku |如何閱讀路由器日誌

回答

相關問題