Node和Java性能对比(仅供参考) - Go语言中文社区

Node和Java性能对比(仅供参考)


背景引出

线上网站遭受攻击,首页被强刷,导致服务器node性能过载,影响用户正常页面访问。

大致架构:客户端发起请求 --> node(充当中间件,访问后端API渲染页面) --> java(处理业务逻辑)--> database

现象&问题

现象 疑惑
Nodejs cup 满负载 与Nodejs高性能不符?
后端 Java 的负载和Node相反 怎么性能会优于Nodejs?

node和java来个简单测试(偏娱乐向)

前期测试准备

分别用以下方式模拟一个线上获取用户信息的接口:

  1. node直连mysql
  2. node调用java接口来获取数据。

框架:koa+koa-router+sequelize+request+pm2

备注:由于不太清楚后端业务数据取值逻辑,尽可能还原response data,会存在一定的数据包偏差。

简要代码

router.all('/api/java', async function(ctx, next) {
    let uid = ctx.cookies.get('uid');
        // request代理给后端java API接口
    ctx.body = await new Http({ctx}).request({
        url: '/user/getbalance'
    })
})
router.all('/api/node', async function(ctx, next) {
    let uid = ctx.cookies.get('uid');
        // 通过sequelize从mysql查询
    let data = await Promise.all([
        user.balance(uid),
        user.integral(uid),
        user.coupon(uid),
        user.memberProp(uid)
    ]);
    ctx.body = data
});

分组测试&结论

在测试环境,直接局域网ab测试,避免网络io损耗。
测试不同并发条件(100->200->500->1k->2k),1w请求总耗时;同时node增加核数(1核->2核->4核->8核)

Java测试(node代理给java)

再次备注:通过node访问java接口。(要模拟线上环境,会因为node的瓶颈造成java负载过低)

图片描述

Node测试

node直连数据库

图片描述

Java&node

直接访问java接口,硬碰硬

图片描述

测试结论

  1. node的强项处理非阻塞异步IO,但由于是单进程,虽然请求数量增加↑,实际到达java应用的请求被限制在一个峰值max,解释了图1红柱:当cpu1核时,并发数增多,耗时不变
  2. 知道了node cpu瓶颈的原因,通过pm2增加核数,让java得到更多的资源去处理。图1深蓝浅蓝:cpu核数增加,耗时缩短
  3. 当cpu升值8核(测试环境满核),node基本不会hold住任何请求(top小于50%),直接丢到java端,到达java请求数倍增,但由于java语言特点(同步阻塞式)、外界因素(测试环境复杂),相反时间没有得到下降而是有上升趋势。图1橘色:有上升趋势
  4. 依托于多核的性能,node充分利用硬件资源,核数增加↑,执行能力正比例上升↑。图2:耗时随cpu核数增加,而倍减
  5. 结合图1,图2:打开cpu限制后,不难发现node性能迅速上升,符合外界宣传,(注:使用了Promise.all更加快了异步处理速度)
  6. 图3:node性能好于java,但并发2k时,两者还是不分上下,还是要分不同场景对2者有个组合使用(注:因为数据库等原因,java在处理业务时,会大批出现jdbc等问题)

计划改进方案

  • 使用pm2修改node运行环境,增加node端处理量,解决node瓶颈
  • 重新设计架构方式,在未来有条件时,能做到node横向水平扩展,避免单台机器cpu瓶颈,能处理高峰压力&恶意攻击
  • 线下进一步了解node性能问题

apach ab

简单介绍

apache ab

运行脚本:ab + 请求数量 + 并发数量 + 测试地址

[root@localhost pressure_analysis]# ab -n 10000 -c 1000 http://127.0.0.1:3301/anal/api/java

参数说明:

指标 数值 说明
Concurrency Level 1000 并发数量
Complete requests 10000 全部完成的请求数量
Time taken for tests 7.907 seconds 运行测试脚本总用时
Total transferred 2880000 bytes 数据包大小
Requests per second 1264.76 [#/sec] (mean) 平均每秒请求数量(Complete requests/Time taken for tests)
Time per request 790.661 [ms] (mean) 单个请求平均耗时(Concurrency Level*Time taken for tests)
Transfer rate 355.71 [Kbytes/sec] received 数据包传输速率

ab工具使用到的一些问题

apr_socket_recv: Connection reset by peer (104)

sysctl命令被用于在内核运行时动态地修改内核的运行参数,可用的内核参数在目录/proc/sys中。它包含一些TCP/ip堆栈和虚拟内存系统的高级选项, 这可以让有经验的管理员提高引人注目的系统性能。
[root@localhost pressure_analysis]# vim /etc/sysctl.conf
net.ipv4.tcp_syncookies = 0

[root@localhost pressure_analysis]# sysctl -p

socket: Too many open files (24)

ulimit用来限制系统用户对shell资源的访问
# 注意到open files限制1024
[root@localhost pressure_analysis]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 257702
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 257702
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

# 修改配置
[root@localhost pressure_analysis]# ulimit  -n 5000

参考

版权声明:本文来源CSDN,感谢博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/weixin_33889245/article/details/88713321
站方申明:本站部分内容来自社区用户分享,若涉及侵权,请联系站方删除。
  • 发表于 2020-02-02 18:00:32
  • 阅读 ( 1970 )
  • 分类:

0 条评论

请先 登录 后评论

官方社群

GO教程

猜你喜欢