Node.js/Express Netflix 问题

Question

我对 Netflix 在 Express 中遇到的这个问题有点困惑。他们开始在 API 中发现延迟。我们所有事情都使用 Express，我希望避免出现任何突发问题。

这是文章的链接。

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

从它的写法来看，这听起来像是 Express 的问题，以及它如何处理路由的问题。但最后，他们声明如下:

“在深入研究源代码后，团队发现了问题。它存在于一个每小时执行 10 次的周期性函数中，其主要目的是从外部源刷新路由处理程序。当团队修复了代码，以便该函数停止添加重复的路由处理程序，延迟和 CPU 使用率的增加消失了。”

我不明白他们到底想做什么。我不相信这是 Express 自己做的事情。听起来他们做了一些有点奇怪的事情，而且没有成功。我认为负载测试会揭示这一点。无论如何，任何更了解这一点的人都可以评论问题到底是什么？文章顶部的整个部分讨论了 Express 如何在路由列表中轮换，但我真的不明白迭代不应该是一个非常大的数组会如何导致那么大的延迟。

Answer 1

我见过的最好的对位解释是 Eran Hammer's 。评论也很有启发性。特别令人感兴趣的是以下摘自肖宇农(Netflix 帖子的作者)评论的摘录:

The specific problem we encountered was not a global handler but the express static file handler with a simple string path. We were adding the same static router handler each time we refreshed our routes. since this route handler was in the global routing array, it meant that every request that was serviced by our app had to iterate though this handler.

It was absolutely our mis-use of the Express API that caused this -- after all, we were leaking that specific handler! However, had Express 1) not stored static handlers with simple strings in the global routing array, and 2) rejected duplicate routing handlers, or 3) not taken 1ms of CPU time to merely iterate through this static handler, then we would not have experienced such drastic performance problems. Express would have masked the fact that we had this leak -- and perhaps this would have bit us down the road in another subtle way.

 

Our application has over 100 GET routes (and growing), even using the Express's Router feature -- which lets you compose arrays of handlers for each path inside the global route array, we'd still have to iterate through all 100 handlers for each request. Instead, we built our own custom global route handler, which takes in the context of a request (including its path) and returns a set of handlers specific to the request such that we don't have to iterate through handlers we don't need.

This was our implementation, which separated the global handlers that every request needs from handlers specific to each request. I'm sure more optimal solutions are out there.