BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Netflix:Express.js性能调优心得

| 作者 João Paulo Marques 关注 0 他的粉丝 ,译者 黄晓雯 关注 0 他的粉丝 发布于 2014年12月11日. 估计阅读时间: 6 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

Netflix的软件工程师Yunong Xiao最近在公司的技术博客上写了一篇文章,分析了他所在的团队在将Netflix网站UI转移到Node.js上时遇到的延迟问题。在文章中他描述了找到问题根本原因所经历的复杂的工程过程,以及他们是怎样做出替换底层API框架的决定。

最初,Yunnong的团队观察到API中某些端点的请求延迟会持续上升(每小时增加10ms),并且在高延迟的时段应用占用的CPU资源超过预期。他们最早的假设是请求处理器的一些问题(例如内存泄露)导致了延迟时间上升。为检验这一假设,他们配置了一个可控的环境,并在该环境下度量请求处理器的延迟和请求的总延迟。此外,他们将Node.js的堆大小增加到32GB。他们观察到,在实验过程中请求处理器的延迟和堆大小始终保持不变,但请求总延迟和CPU占用率持续增加。

接下来,他们用CPU火焰图和Linux的Perf Events工具分析CPU使用情况。在仔细分析火焰图(如下图)后,工程师们发现图中很多方框指向Express.js的router.handle和router.handle.next函数。

深入研究Express.js代码库后,工程师们发现:

  • 所有端点的路由处理器(route handler)保存在一个全局数组里
  • Express.js采用递归遍历所有路由处理器直至找到正确的处理器并调用

正如Yunong所述:

在这种情况下全局数组并不是理想的数据结构。不知道为什么Express.js不采用例如map这样的查询时间为常数的数据结构。更有甚者,数组是递归遍历的。这就解释了为什么会在火焰图里看到这么高的堆。有趣的是,Express.js甚至允许你给单个路由设置多个相同的路由处理器,比如:[a, b, c, c, c, c, d, e, f, g, h]。

请求路由c时,程序会在第一次出现c处理器的位置终止(数组中下标为2的位置)。但是请求d时只会在数组下标6的位置停止,其实不必花费时间遍历a,b和多个c。

为了更清楚地了解Express.js怎么样存储路由,工程师们创建了如下示例:

 var express = require('express');
 var app = express();
 app.get('/foo', function (req, res) {
    res.send('hi');
 }); 
 // add a second foo route handler
 app.get('/foo', function (req, res) {
    res.send('hi2');
 });
 console.log('stack', app._router.stack);
 app.listen(3000);

以上代码产生如下结果:

 stack [ { keys: [], regexp: /^\/?(?=/|$)/i, handle: [Function: query] },
  { keys: [],
    regexp: /^\/?(?=/|$)/i,
    handle: [Function: expressInit] },
  { keys: [],
    regexp: /^\/foo\/?$/i,
    handle: [Function],
    route: { path: '/foo', stack: [Object], methods: [Object] } },
  { keys: [],
    regexp: /^\/foo\/?$/i, 
    handle: [Function],
    route: { path: '/foo', stack: [Object], methods: [Object] } } ]

从运行结果可以推断出Express.js没有正确地处理重复的路由处理器。Yunong指出:“注意到对于路由/foo,有两个完全一样的路由处理器。更好的方式是,当路由处理器链中出现一个路由有多个路由处理器的情况时,Express.js抛出错误。”

深入分析应用源码后,工程师们发现一个周期函数是出现重复路由器的罪魁祸首。这个函数每小时执行10次,而其目的是为了从外部刷新路由处理器。当团队修改了程序,使得函数不再增加重复的路由处理器后,高延迟和燃烧CPU的问题就随之消失了。

经历这一插曲后,Yunong总结了团队得出几个结论:

首先,在程序投入使用前我们要完全清楚它们的依赖关系。我们没有对Express.js的代码库做深入分析就对它做出了错误的假设,导致我们错误地使用了Express.js的API,这才是造成性能问题的根本原因。

其次,在处理性能问题时,可观测性是极其重要的。火焰图帮助我们洞悉程序的CPU占用情况。如果不能抽样并用火焰图可视化Node.js堆栈使用情况,我无法想象该怎样解决我们的问题。

为了进一步提升可观测性,我们正在迁移到Restify。Restify能提供更好的透视性、可视化以及对应用更好的控制。

查看英文原文:Netflix Burned By Express.js


感谢崔康对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT