Node.js服务性能
起因
近期,反映Node.js服务慢,表现为页面卡顿,加载慢,超时等。甚至运维人员有反映服务器不响应的情况。针对这种情况,我对服务性能进行了一些简单的分析,主要原因有以下几点:
- 页面的初始化逻辑复杂
- 有部分无用的代码,占用了服务器的运行时间
- 服务动态加载的文件比较大,加载的效果不够高
解决方案
针对这些问题,页面的逻辑部分,已向生产部门的开发的同事在周三的例会上多次强调服务效率问题,希望能引起开发人员的重视。无用代码部分,计划对项目添加语法规范检查,暂未实施,计划与第三个问题一同实施。
针对第三个问题,计划做两方面的处理:
- 不打包服务代码,只压缩
- 本地开发测试使用本地服务,不使用服务器资源
测试结果
首先对代码进行不打包处理(暂定框架版本号4.1.0),使用的页面为feidao_400项目中的new-question-list.html
页面,该页面初始化一共调用了6个Node.js服务,为了确保测试的时间的准确性,以下测试均略去服务开启后首次调用的情形,且每种情形都连续进行了10次采样。
第一轮测试:
4.0(即现在服务器上运行的框架版本,js服务部分压缩,部分合并)
服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|
24 | 32 | 81 | 216 | 27 | 20 |
59 | 70 | 34 | 226 | 28 | 27 |
58 | 58 | 105 | 206 | 31 | 22 |
63 | 124 | 75 | 214 | 34 | 43 |
34 | 40 | 54 | 125 | 52 | 93 |
126 | 169 | 254 | 372 | 26 | 19 |
19 | 26 | 48 | 221 | 34 | 20 |
25 | 30 | 42 | 185 | 25 | 33 |
72 | 74 | 80 | 270 | 39 | 42 |
76 | 89 | 160 | 278 | 27 | 41 |
服务的平均执行时间
总体 | 服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|---|
86.6167 |
55.6 | 71.2 | 93.3 | 231.3 | 32.3 | 36 |
4.1.0(所有服务均为源码,未压缩,未合并)
服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|
66 | 84 | 120 | 278 | 31 | 39 |
70 | 134 | 82 | 264 | 40 | 45 |
71 | 50 | 103 | 248 | 46 | 21 |
25 | 25 | 44 | 157 | 27 | 49 |
91 | 71 | 128 | 216 | 40 | 40 |
33 | 34 | 59 | 180 | 27 | 30 |
22 | 24 | 35 | 145 | 31 | 24 |
20 | 27 | 20 | 159 | 30 | 20 |
71 | 71 | 129 | 228 | 47 | 35 |
61 | 65 | 77 | 178 | 43 | 19 |
服务的平均执行时间
总体 | 服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|---|
77.4833 |
53 | 58.5 | 79.7 | 205.3 | 36.2 | 32.2 |
小结一
在不打包的情况下,因为可以使用缓存,且更适合nodejs的运行机制,所以其执行效率有所提升,约提升百分之10
第二轮测试:
4.0
服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|
70 | 78 | 129 | 638 | 40 | 34 |
60 | 73 | 108 | 249 | 56 | 114 |
62 | 76 | 134 | 283 | 31 | 26 |
104 | 102 | 181 | 384 | 50 | 37 |
100 | 106 | 168 | 540 | 49 | 62 |
33 | 39 | 52 | 191 | 43 | 29 |
70 | 78 | 143 | 249 | 41 | 36 |
63 | 111 | 72 | 245 | 34 | 33 |
80 | 121 | 136 | 432 | 54 | 37 |
76 | 82 | 146 | 326 | 51 | 32 |
总体 | 服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|---|
121.3167 |
71.8 | 86.6 | 126.9 | 353.7 | 44.9 | 44 |
4.1.1(所有服务压缩但未合并)
服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|
96 | 126 | 176 | 327 | 73 | 38 |
65 | 70 | 86 | 160 | 36 | 30 |
66 | 65 | 83 | 204 | 54 | 25 |
112 | 121 | 140 | 241 | 39 | 75 |
33 | 52 | 61 | 161 | 51 | 38 |
41 | 39 | 45 | 167 | 48 | 29 |
68 | 74 | 112 | 198 | 60 | 38 |
76 | 88 | 157 | 319 | 54 | 32 |
44 | 45 | 60 | 174 | 30 | 47 |
61 | 62 | 134 | 249 | 65 | 49 |
总体 | 服务1 | 服务2 | 服务3 | 服务4 | 服务5 | 服务6 |
---|---|---|---|---|---|---|
92.8167 |
66.2 | 74.2 | 105.4 | 220 | 51 | 40.1 |
小结二
在不打包的情况下,因为可以使用缓存,且更适合nodejs的运行机制,所以其执行效率有所提升,约提升百分之23
注意
需要注意的是,第一轮测试与第二轮测试时间段相关太大,所以第一轮和第二轮的测试4.1的测试结果无可比性,但之前做过此类测试,压缩后性能是有提升的(理论上讲也是这样)。这可以从使用4.0框架的服务时间上(4.0框架的服务一直没动,只不过运行的时间段不一样而已,应该是这两个时间段数据库服务的响应时间有差异)看出来。
此次框架调整能提高一部分性能,但是,性能问题需要多部门合作,非是只靠框架就可以的。需要配合的部门有:
- 方案
- 培训
- 工厂
归根结底,是人的问题,也是看似容易但实际最难的问题。