2011-06-01 41 views
1

因此,這裏是我的要求的最後一行:我該如何判斷我的請求如此長久?

Completed in 9209ms (View: 358, DB: 1582) 

所以我需要弄清楚發生了什麼阻礙了該請求。這個請求可能會超過一分鐘,所以我真的需要弄清楚這一點。如果數據庫和視圖需要1.9秒,那麼意味着日誌中有7.2秒未被記錄下來。我如何進一步分析代碼的其他部分?如果知道是否有一個回調是造成延遲的主要原因,那該多好。

+0

你在生產或開發中看到這些數字嗎? – moritz 2011-06-01 22:44:44

+0

@mosch開發和生產。 – solidcell 2011-06-03 06:03:47

回答

0

通常不在數據庫或視圖中的代碼位於控制器中(或者它可能位於模型的邏輯部分中)。我遇到的最大的罪魁禍首是循環內的循環,或無償使用:include => {...stuff...}

+0

':include'的用法不屬於DB,因此成爲'DB:1582'的一部分? – solidcell 2011-06-06 21:50:50

+0

'DB:'時間只包括數據庫進程運行的時間。它不包括Rails爲實例化對象和建立關聯所做的處理。如果你有一個深嵌套的':include',這可能會變得非常重要 – Gareth 2011-06-07 11:31:52

0

您是否正在實現數據庫中的大量記錄?查詢時間可能不多,但如果我說從數據庫中使用非常簡單而快速的查詢選擇了10,000條記錄,我仍然期望我的頁面加載時間很長,因爲它會花費大量的時間來保溼大的記錄集。

我建議運行一些性能測試(rake test:profile)。這些應該給你一個大部分時間花在哪裏的指示。你可能會發現只有一兩個方法調用被調用的頻率過高。

相關問題