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个处理程序。相反，我们构建了我们自己的自定义全局路由处理程序，该处理程序接受 请求（包括其路径）的上下文，并返回一组特定于 请求的处理程序，以便我们不必遍历处理程序我们 不需要。

这是我们的实现，它将每个请求需要的全局处理程序与特定于每个请求的处理程序分开。我确信 更优化的解决方案在那里。