背景引出
线上网站遭受攻击，首页被强刷，导致服务器node性能过载，影响用户正常页面访问。
大致架构：客户端发起请求 --> node（充当中间件，访问后端API渲染页面） --> java（处理业务逻辑）--> database
现象&问题
| 现象 | 疑惑 |
|---|---|
| Nodejs cup 满负载 | 与Nodejs高性能不符？ |
| 后端 Java 的负载和Node相反 | 怎么性能会优于Nodejs？ |
node和java来个简单测试（偏娱乐向）
前期测试准备
分别用以下方式模拟一个线上获取用户信息的接口：
- node直连mysql
- 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接口，硬碰硬
测试结论
- node的强项处理非阻塞异步IO，但由于是单进程，虽然请求数量增加↑，实际到达java应用的请求被限制在一个峰值max，解释了图1红柱：当cpu1核时，并发数增多，耗时不变
- 知道了node cpu瓶颈的原因，通过pm2增加核数，让java得到更多的资源去处理。图1深蓝浅蓝：cpu核数增加，耗时缩短
- 当cpu升值8核（测试环境满核），node基本不会hold住任何请求（top小于50%），直接丢到java端，到达java请求数倍增，但由于java语言特点（同步阻塞式）、外界因素（测试环境复杂），相反时间没有得到下降而是有上升趋势。图1橘色：有上升趋势
- 依托于多核的性能，node充分利用硬件资源，核数增加↑，执行能力正比例上升↑。图2：耗时随cpu核数增加，而倍减
- 结合图1，图2：打开cpu限制后，不难发现node性能迅速上升，符合外界宣传，（注：使用了Promise.all更加快了异步处理速度）
- 图3：node性能好于java，但并发2k时，两者还是不分上下，还是要分不同场景对2者有个组合使用（注：因为数据库等原因，java在处理业务时，会大批出现jdbc等问题）
计划改进方案
- 使用pm2修改node运行环境，增加node端处理量，解决node瓶颈
- 重新设计架构方式，在未来有条件时，能做到node横向水平扩展，避免单台机器cpu瓶颈，能处理高峰压力&恶意攻击
- 线下进一步了解node性能问题
apach 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.confnet.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 -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimitedscheduling priority (-e) 0file size (blocks, -f) unlimitedpending signals (-i) 257702max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimitedopen files (-n) 1024pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 10240cpu time (seconds, -t) unlimitedmax user processes (-u) 257702virtual memory (kbytes, -v) unlimitedfile locks (-x) unlimited# 修改配置[root@localhost pressure_analysis]# ulimit -n 5000