请选择 进入手机版 | 继续访问电脑版

技术控

    今日:203| 主题:53462
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Node 性能优化

[复制链接]
城府 发表于 2016-11-28 17:12:05
164 5

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
前言

  没有 profile 谈优化都是耍流氓,性能优化的大前提是 profile ,有数据才能找出程序慢在哪里了。
   本篇文章主要介绍 Node 后端的性能优化,前端的同学可以看看 Chrome 的 devtools https://github.com/CN-Chrome-...
  一、Web 应用优化

  性能的瓶颈往往在 IO
  IO 层优化

  磁盘 IO 为什么慢

  计算机里的常见 IO 有 :
  
       
  • CPU 一二级缓存
       
  • 内存
       
  • 硬盘
       
  • 网络
      
  硬盘的 IO 开销是非常昂贵的,硬盘 IO 花费的 CPU 时钟周期是内存的 41000000/250 = 164000 倍。
  所有在一般应用中,优化要首先考虑数磁盘 IO , 通常也就是数据层的优化,说到数据库优化,很多人第一时间会想到加索引,但是什么加了索引查询会变快呢?索引要怎么加才合适呢?
  为什么索引快

   关于索引的原理可以看看这篇文章, 索引原理 。索引快主要的原因是:
  
       
  • 索引占用空间更小,可以有效减少磁盘 IO 次数。
       
  •   索引可以使用方便快速查询的数据结构,如 b+树
      
  索引怎么加

   回到我们的主题, 没有 profile 谈优化都是耍流氓
  以 mongo 为例,mongo 是带有慢查询功能的。
   MongoDB 查询优化分析 这篇文章介绍了如何开启和使用 mongo 的慢查询功能。
  开启慢查询收集功能后,使用 db.system.profile.find().pretty() 语句可以查询到哪些语句的查询比较慢。以下面这个查询语句为例:
  1. query new_koala.llbrandomredpackage query: { user_id: "56ddb33e23db696f89fdae2a", status: { $ne: 1 } }
复制代码
查询条件是 user_id、status 两个,所以给这两个字段加上索引可以提高查询速度。
  当然,如果 mongo 没有是先开启慢查询,扫描一下 mongo.log 也是个办法。
  1. grep '[0-9][0-9][0-9]ms' /var/log/mongodb/mongodb.log
复制代码
这样就可以找出所有查询耗时大于100 ms 的记录。然后再对症下药即可。
  缓存大法好,有选择地用。

  上文有说到,内存 IO 比磁盘 IO 快非常多,所以使用内存缓存数据是有效的优化方法。常用的工具如 redis、memcached 等。
   缓存效果显著,所以很多时候一谈到优化,很多人就会想到加缓存,但是使用缓存是有代价的,你需要维护缓存的更新和失效,这是个 繁琐 的事情,用上了缓存后你会经常碰到缓存没有及时更新带来的问题。
  重要的事情说多几遍:
   缓存有副作用
   缓存有副作用
   缓存有副作用
   并不是所有数据都需要缓存, 访问频率高,生成代价比较高 的才考虑是否缓存,也就是说影响你性能瓶颈的考虑去缓存。
   而且缓存还有 缓存雪崩缓存穿透 等问题要解决。见 缓存穿透与缓存雪崩
  静态文件缓存

  静态文件如图片、js 文件等具有不变性,是非常适合做缓存的。
  常见的静态文件缓存服务有 nginx、vanish 等。
  代码层面优化。

  合并查询

  在代码这一块,常做的事情是将多次的查询合并为一次,消灭 for 循环,实际上还是减少数据库查询。例如
  1. for user_id in userIds
  2.      var account = user_account.findOne(user_id)
复制代码
这类代码实际上可以改写成:
  1. var user_account_map = {}   // 注意这个对象将会消耗大量内存。
  2. user_account.find(user_id in user_ids).forEach(account){
  3.     user_account_map[account.user_id] =  account
  4. }
  5. for user_id in userIds
  6.     var account = user_account_map[user_id]
复制代码
这样就把 N 次的查询合并为一次。
  实际上还是为了减少 IO。
  关于过早优化

     性能优化的工作做多了以后,往往会陷入一个什么都想着去优化的状态,这样就可能陷入过早优化的深坑中。
   这里引用一下其他人的观点
    https://www.zhihu.com/questio...
   

Node 性能优化

Node 性能优化
    二、内存泄露排查

  Node 是基于 V8 这个 js 引擎的,这里我们了解下 V8 里的内存相关的知识。
  V8 的 GC 垃圾回收机制

  V8 的内存分代

  在 V8 中,主要将内存分为新生代和老生代两代。新生代的对象为存活时间比较短的对象,老生代中的对象为存活时间较长的或常驻内存的对象。
  默认情况下,新生代的内存最大值在 64 位系统和 32 位系统上分别为 32 MB 和 16 MB。V8 对内存的最大值在 64 位系统和 32 位系统上分别为 1464 MB 和 732 MB。
  为什么这样分两代呢?是为了最优的 GC 算法。新生代的 GC 算法 Scavenge 速度快,但是不合适大数据量;老生代针使用 Mark-Sweep(标记清除) & Mark-Compact(标记整理) 算法,合适大数据量,但是速度较慢。分别对新旧两代使用更适合他们的算法来优化 GC 速度。
  详情参见《深入浅出 nodejs》5.1 V8 的垃圾回收机制与内存限制
  V8 的 GC log

  在启动程序的时候添加 --trace_gc 参数,V8 在进行垃圾回收的时候,会将垃圾回收的信息打印出来:
  1. ➜  $ node --trace_gc aa.js
  2. ...
  3. [94036]       68 ms: Scavenge 8.4 (42.5) -> 8.2 (43.5) MB, 2.4 ms [allocation failure].
  4. [94036]       74 ms: Scavenge 8.9 (43.5) -> 8.9 (46.5) MB, 5.1 ms [allocation failure].
  5. [94036] Increasing marking speed to 3 due to high promotion rate
  6. [94036]       85 ms: Scavenge 16.1 (46.5) -> 15.7 (47.5) MB, 3.8 ms (+ 5.0 ms in 106 steps since last GC) [allocation failure].
  7. [94036]       95 ms: Scavenge 16.7 (47.5) -> 16.6 (54.5) MB, 7.2 ms (+ 1.3 ms in 14 steps since last GC) [allocation failure].
  8. [94036]      111 ms: Mark-sweep 23.6 (54.5) -> 23.2 (54.5) MB, 6.2 ms (+ 15.3 ms in 222 steps since start of marking, biggest step 0.3 ms) [GC interrupt] [GC in old space requested].
  9. ...
复制代码
V8 提供了很多程序启动选项:
              启动项     含义                   –max-stack-size     设置栈大小             –v8-options     打印 V8 相关命令             –trace-bailout     查找不能被优化的函数,重写             –trace-deopt     查找不能优化的函数           使用 memwatch 模块来检测内存泄露

  npm模块 memwatch 是一个非常好的内存泄漏检查工具,让我们先将这个模块安装到我们的app中去,执行以下命令:
  1. npm install --save memwatch
复制代码
然后,在我们的代码中,添加:
  1. var memwatch = require('memwatch');
复制代码
然后监听 leak 事件
  1. memwatch.on('leak', function(info) {
  2. console.error('Memory leak detected: ', info);
  3. });
复制代码
这样当我们执行我们的测试代码,我们会看到下面的信息:
  1. {
  2. start: Fri Jan 02 2015 10:38:49 GMT+0000 (GMT),
  3. end: Fri Jan 02 2015 10:38:50 GMT+0000 (GMT),
  4. growth: 7620560,
  5. reason: 'heap growth over 5 consecutive GCs (1s) - -2147483648 bytes/hr'
  6. }
  7. mem
复制代码
memwatch 发现了内存泄漏!memwatch 判定内存泄漏事件发生的规则如下:
  当你的堆内存在5个连续的垃圾回收周期内保持持续增长,那么一个内存泄漏事件被派发

   了解更加详细的内容,查看 memwatch
  使用 heapdump dump 出 Node 应用内存快照

  检测到了内存泄露的时候,我们需要查看当时内存的状态,heapdump 可以抓下当时内存的快照。
  1. memwatch.on('leak', function(info) {
  2. console.error(info);
  3. var file = '/tmp/myapp-' + process.pid + '-' + Date.now() + '.heapsnapshot';
  4. heapdump.writeSnapshot(file, function(err){
  5.    if (err) console.error(err);
  6.    else console.error('Wrote snapshot: ' + file);
  7.   });
  8. });
复制代码
运行我们的代码,磁盘上会产生一些 .heapsnapshot 的文件到/tmp目录下。
  使用 Chrome 的开发者工具分析内存消耗

     heapdump 提供的内存快照是可以用 Chrome 的开发者工具来查看的。把 .heapsnapshot 文件导入到 Chrome Developer Tools
   

Node 性能优化

Node 性能优化
   

Node 性能优化

Node 性能优化
    怎么使用内存分析工具呢?
   Chrome开发者工具之JavaScript内存分析
  这篇文件详细介绍了如何使用开发者工具来分析内存的使用情况。可以参考,这里就不细说了。
  摘取个例子,使用对比视图。
   对比视图 demo
  这个例子展示了通过对比前后的内存变化来找出内存泄露的原因,看起来还是很简单方便的。
     但是,理想很美好,现实很残酷。下面展示下日常开发中 dump 下的数据。
   使用对比视图:
   

Node 性能优化

Node 性能优化
    可以看出 array 是内存增长的主要元凶,但也只能得到这个线索,那具体是那些 array 消耗了内存呢?
  点开 array 查看详细信息:
   

Node 性能优化

Node 性能优化

  一大堆的匿名数组,无法准确查到具体那些 array 消耗了内存。
  主要原因是后端使用了 sails 这个 web 框架,框架里的代码量比较多,干扰项太多,无法准确地判断是哪些 function 出现了问题。
  内存泄露原因

  通常,造成内存泄露的原因有如下几个。
  
       
  • 慎用内存当缓存,非用的话控制好缓存的大小和过期时间,防止出现永远无法释放的问题
       
  • 队列消费不及时,数组、回调,生产者的速度比消费者速度快,堆积了大量生产者导致无法释放作用域或变量
       
  • 作用域未释放,无法立即回收的内存有全局变量和闭包,尽量使用变量赋值为 null|undefined 来触发回收
      
  这部分的详细解释请参考《深入浅出 nodejs》5.4 内存泄露。
  三、优化应用 CPU 瓶颈

  上面介绍了 IO 优化,内存优化,使用 Node 做后端的话还会经常碰到 CPU 瓶颈。总所周知,Node 是单线程的,所以对 CPU 密集的运算不是太胜任,所以应该避免使用 Node 来进行 CPU 密集的运算。
  那么如果出现了 CPU 类的问题要怎么处理呢?
  V8log:

  加入 --prof 参数可以在应用结束是收集 log,执行命令之后,会在该目录下产生一个 *-v8.log 的日志文件,我们可以安装一个日志分析工具 tick
  tick 工具分析 log

  可以分析每个 function 的处理时间。
  1. grep '[0-9][0-9][0-9]ms' /var/log/mongodb/mongodb.log0
复制代码
前端的同学可以直接在 chrome 里收集 cpu profile 用于分析。
  四、使用第三方平台

   alinode ,基于 Node 运行时的应用性能管理解决方案,笔者没有体验过,不预评价。
  五、总结

  文章主要介绍的还是后端开发中如何做性能优化的几种方式:
  
       
  • 添加索引
       
  • 接口缓存
       
  • 静态文件缓存
       
  • 合并查询
    这几种方法的目的其实都是为了减少 IO。看来 IO 过高是 Node 应用反应慢的主要原因。
      
  此外,文章也介绍了如何排查处理内存泄露和 CPU 过高的问题。这两类问题是也是影响 Node 性能的一大原因。
   这篇文章也同样发表在我的个人博客中,欢迎访问: http://myfjdthink.com/?p=878
  参考:

     《深入浅出 nodejs》朴灵著
    MySQL索引原理及慢查询优化
    MongoDB 查询优化分析
    如何用redis/memcache做Mysql缓存层?
    缓存穿透与缓存雪崩
    http://www.barretlee.com/blog...
    http://www.w3ctech.com/topic/842
    https://addyosmani.com/blog/t...
    http://m.oschina.net/blog/270248
    http://www.cnblogs.com/consta...
   http://www.open-open.com/lib/...



上一篇:[iOS] A Simple And Minimalist iOS AlertController
下一篇:写正则不要再瞎转义了
女圭女圭音せ 发表于 2016-11-28 20:42:46
路过,我是来打酱油的!
回复 支持 反对

使用道具 举报

RenatoLyki 发表于 2016-11-28 21:30:11
我也来顶一下..
回复 支持 反对

使用道具 举报

越qfjgc 发表于 2016-11-28 22:04:07
顶贴不认真,大脑有问题。
回复 支持 反对

使用道具 举报

cvzco 发表于 2016-11-28 22:45:34
楼上的很有激情啊!
回复 支持 反对

使用道具 举报

wapdp 发表于 2016-12-20 06:18:05
幸福毕竟不是曹操,怎能说到就到。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )

© 2001-2017 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表