前言
周末的公司其实挺好的,安静。今日早读文章由腾讯@LucasTwilightl授权分享。
正文从这开始~~
随着Node v11.0 release版本的发布,Node已经走过了很多年。基于Node产生了很多服务端框架,来帮助我们独立于后端进行前端工程的开发和部署。
业务逻辑的迁移,以及各种MV*框架的服务端渲染模型的出现,让基于Node的前端SSR策略更依赖服务器性能。首屏直出性能以及Node服务的稳定性,直接关系影响着用户体验。
Node作为服务端语言,相比于Java和PHP这种老服务端语言来说,对于整体性能的调控还是不够完善。虽然有sentry这种报警平台来及时通知发生的错误,但是不能够预防错误的发生。
如何防患于未然,首先需要理解Node.js性能监控的主要指标。
下面的代码均是基于Egg框架的,如果对Egg不熟悉的小伙伴可以先去浏览一下文档
指标
服务器的资源瓶颈主要有下面几个:
CPU
内存
磁盘
I/O
网络
考虑到不同的Node环境,其对于资源的需求类型也是不尽相同的。如果Node只是用于前端SSR的话,那么CPU和网络就会成为主要的性能瓶颈。
当然如果你需要使用Node来进行数据持久化相关的工作,那么I/O和磁盘也会有很高的占用率。
即使是前端发展非常超前的公司,也很少会用Node作为业务数据的支撑。充其量当做BFF层来为前端提供数据服务,并不直接接触持久化的数据。所以磁盘和I/O很难成为当下前端性能的瓶颈。
即使存在使用Node进行数据持久化平台,大多数也是实验性质的平台或者是内部平台。不直接面向业务场景。
所以,在大多数场景下,CPU、内存以及网络就可以说是Node的主要性能瓶颈。
CPU指标
CPU负载和CPU使用率
顾名思义,这两个指标都是用来评估系统当前CPU的繁忙程度的量化指标。CPU负载和CPU使用率是从两个不同的角度来量化CPU的繁忙程度的。
CPU负载:进程角度
CPU使用率:CPU时间分配
进程是资源分配的最小单位。
这句话在操作系统的教科书上或者各位的考试卷上都多多少少出现过。也就是,系统按照进程级别来进行资源的分配,一个CPU核心在一个时刻只能够为4个进程提供服务。
那么, CPU的负载也就很好理解了。在某个时间段内,占用以及等待CPU的进程总数就是CPU在这个时间段内的负载(load average),在大多数情况下,我们称这个标准为loadavg。
而CPU利用率(cpu utilization),则是量化CPU时间占用状况的,一般我们认为CPU利用率 = 1 - 空闲CPU时间(idle time) / CPU总时间。
量化CPU指标
那么这两个指标到底哪个才最能代表的系统的实际状态呢?
滑梯:CPU
人:进程
假如有4个滑梯。每个滑梯上最多可以塞得下10个人。我们假设所有的人的大小一致。
那么,可以得到如下的类比:
Loadavg = 0,表示滑梯上一个人都没有
Loadavg = 0.5, 表示平均每个滑梯上的人都占了滑梯的一半,也就是总共20个人在滑梯上,由于CPU调度策略,这些人一般会均匀分配(每个人都会挑人少的滑梯)
Loadavg = 1,表示每个滑梯上都塞满人了,没有任何空闲空间
Loadavg = 2&