Node.js/Express Netflix問題

Question

Netflix遇到了這個問題，我對此感到有些困惑。他們開始在他們的API中看到延遲的構建。我們使用Express來處理所有事情，並且我想避免任何突發問題。

這裏是文章的鏈接。

http://www.infoq.com/news/2014/12/expressjs-burned-netflix

它的編寫方式，這聽起來像快遞的問題，以及它如何處理路由。但最終，他們聲明如下：

「在深入瞭解其源代碼後，團隊發現了問題，它駐留在一個週期性函數中，該函數每小時執行10次，其主要目的是刷新路由來自外部來源的處理程序當團隊修復代碼以使該函數停止添加重複的路由處理程序時，延遲和CPU使用率增加就會消失。

我不明白他們究竟想要做什麼。我不相信這是Express自己做的事情。聽起來他們做了一些古怪的事情，但沒有成功。我認爲負載測試會揭示這一點。無論如何，誰能更好地理解這個問題誰能評論問題實際上是什麼？本文頂部的整個部分討論Express如何通過路由列表進行輪換，但我真的不知道如何迭代不應該是一個非常大的數組會導致很大的延遲。

Answer 1

我見過的最好的對比解釋是Eran Hammer's。評論也很有啓發。特別感興趣的是從雨農蕭的（Netflix的帖子的作者）評論以下摘錄：

我們所遇到的具體問題不是一個全球性的處理程序，但 表達一個簡單的路徑字符串靜態文件處理程序。每次我們刷新路由時，我們都添加了相同的靜態路由器處理程序 。 由於此路由處理程序位於全局路由數組中，因此意味着 由我們的應用程序提供服務的每個請求都必須重複此處理程序的 。

這絕對是我們錯誤地使用Express API造成的 - 畢竟，我們泄漏了特定的處理程序！但是，Express 1）在全局的 路由數組中沒有存儲靜態句柄，並且2）拒絕了重複的路由處理程序，或者3）不是 ，只花費1ms的CPU時間來遍歷這個靜態句柄，然後我們不會遇到如此劇烈的性能問題。 Express可能掩蓋了我們有這個漏洞的事實 - 也許這會讓我們以另一種微妙的方式走上一條路。

 

我們的應用程序有超過100送路由（和不斷增長），即使使用 快速的路由器的功能 - 它可以讓你譜寫處理 的陣列來全球航線陣列中的每個路徑，我們仍然需要 遍歷每個請求的所有100個處理程序。相反，我們構建了我們自己的自定義全局路由處理程序，該處理程序接受 請求（包括其路徑）的上下文，並返回一組特定於 請求的處理程序，以便我們不必遍歷處理程序我們 不需要。

這是我們的實現，它將每個請求需要的全局處理程序與特定於每個請求的處理程序分開。我確信 更優化的解決方案在那裏。