2013-12-20 148 views
2

我對性能優化很陌生,儘管我認識到nodejs可能不是最適合初學者的友好開始,但它是當前的任務。Nodejs性能優化

觀察結果:簡單的JSON API請求在數據庫中的空載服務器和數據庫用戶的登臺服務器上需要幾百毫秒的量級。特別是,在調用/ API/GET_USER正在〜300ms的

執行該代碼:

exports.get_user = function(req, res) { 
    return res.json(req.user) 
} 

(注:我們提供的會話存儲在Redis的)

堆棧:

  • 的NodeJS
  • 快遞
  • Redis的
  • 蒙戈

從哪裏開始?

+0

你如何初始化'req.user'? – srquinn

+1

這裏確實沒有足夠的信息來猜測你正在碰到什麼問題。 – loganfsmyth

+0

請指定您的服務(節點,redis,mongo)在何處出現。提供一個實際執行的更大的代碼片段。此外,通過在執行的腳本中添加console.log(new Date()),通常很容易確定時間採取操作。 – igorpavlov

回答

1

雖然這可能是對這個小場景的矯枉過正,但您可能需要考慮分析。我發現nodetime.com服務非常有用。

+0

通過整個代碼我在nodetime上運行/ api/get_user上的事務配置文件並得到12.9ms:[nodetime screenshot](https://dl.dropboxusercontent。 COM/U/3826044/nodeprofile/nodetime_transaction.png)。 但是,在chrome開發工具上的相同請求顯示607毫秒:[開發工具屏幕截圖](https://dl.dropboxusercontent.com/u/3826044/nodeprofile/devtools_roundtrip.png)。 由於nodetime只是測量節點生成請求需要多長時間,我是否應該假設差異是請求通過開放式Internet傳輸所花費的時間? – max

+0

是的,這是一個合理的假設。我不知道有關您的部署拓撲的詳細信息。您的線路上可能存在延遲,或者您可能花時間在dns分辨率上。此外,您可能想要測量一連串的請求,丟棄前幾個,這往往會因加載時間而延長。 –

+0

我發現nginx的limit_req指令過於嚴格,並且對大多數延遲負責。謝謝。 – max

0

傳遞–-nouse_idle_notification標誌會告訴V8忽略來自節點的空閒通知調用,這是對V8的請求,要求它立即運行GC,因爲節點進程當前處於空閒狀態。由於節點對這些調用很積極(效率高,乾淨),過量的GC可能會減慢應用程序的運行速度。請注意,使用此標誌不會禁用GC; GC運行頻率較低。在正確的情況下,這種技術可以提高性能。