服务压力测试

参考文章：

• https://juejin.im/post/5b827cbbe51d4538c021f2da
• https://github.com/mcollina/autocannon

文章你所能了解的内容：

1. 压力测试能做什么
2. 怎么进行压力测试
3. 如何分析压力测试结果

简介

当系统开发完成后，为了了解系统最大能够承受的并发量和在并发情况下的服务器负载情况，我们就需要在系统上线之前进行一些压力测试，了解系统的性能瓶颈，针对性进行优化。

负载测试指标：

1. TPS 经常是业务核心逻辑测试结果的单位，它的定义是：系统每秒最多能够处理的请求数量。

压力测试

做压力测试的工具有很多，例如：loadTest,ab,autocannon 等

这里我选用的是 autocannon ，因为它能够配合 node-clinic 进行性能优化。

安装

npm i -g autocannon

参数

• -c :并发数量，默认为 10
• -d :压力测试持续的时间，默认为 10 秒
• -p :单个并发每秒发送的请求数量，默认为 1 次
• -m :请求类型,默认为 GET
• -b :请求报文体

实测

控制台运行

demo1

• 负载测试配置:10 个并发量，每个每秒发送 1 个请求，持续时间为 10 秒。
• 测试的接口没有任何处理，非常的简单

# 启动服务器
$ node ./child-process-cpu-server.js

$ autocannon -c 10 -d 10 -p 1 localhost:3002
Running 10s test @ http://localhost:3002
10 connections

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬─────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max     │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼─────────┤
│ Latency │ 0 ms │ 0 ms │ 2 ms  │ 2 ms │ 0.27 ms │ 0.65 ms │ 28.5 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴─────────┘
┌───────────┬────────┬────────┬─────────┬─────────┬──────────┬─────────┬────────┐
│ Stat      │ 1%     │ 2.5%   │ 50%     │ 97.5%   │ Avg      │ Stdev   │ Min    │
├───────────┼────────┼────────┼─────────┼─────────┼──────────┼─────────┼────────┤
│ Req/Sec   │ 5143   │ 5143   │ 11047   │ 11967   │ 10490.73 │ 1790.16 │ 5140   │
├───────────┼────────┼────────┼─────────┼─────────┼──────────┼─────────┼────────┤
│ Bytes/Sec │ 1.1 MB │ 1.1 MB │ 2.36 MB │ 2.56 MB │ 2.24 MB  │ 383 kB  │ 1.1 MB │
└───────────┴────────┴────────┴─────────┴─────────┴──────────┴─────────┴────────┘

Req/Bytes counts sampled once per second.

115k requests in 11.08s, 24.7 MB read

在接下来我将并发数提升为 20，获得的结果与之前基本一致，可以我们就可以获得结果：

• 10 秒总共发送了 115k 请求
• 每个请求平均被处理的时间是 0.27 ms
• 平均每秒能够处理的请求是 10490 个，TPS 等于：10490

demo2

• 负载测试配置:10 个并发量，每个每秒发送 1 个请求，持续时间为 10 秒。
• 测试的接口包含了一段复杂的算法

# 启动服务器
$ node ./child-process-cpu-server.js

$ autocannon -c 10 -d 10 -p 1 localhost:3002/fib?m=30
Running 10s test @ http://localhost:3002/fib?m=30
10 connections

┌─────────┬────────┬────────┬────────┬────────┬───────────┬──────────┬───────────┐
│ Stat    │ 2.5%   │ 50%    │ 97.5%  │ 99%    │ Avg       │ Stdev    │ Max       │
├─────────┼────────┼────────┼────────┼────────┼───────────┼──────────┼───────────┤
│ Latency │ 226 ms │ 322 ms │ 495 ms │ 522 ms │ 328.59 ms │ 56.93 ms │ 532.35 ms │
└─────────┴────────┴────────┴────────┴────────┴───────────┴──────────┴───────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬───────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼───────┼─────────┤
│ Req/Sec   │ 26      │ 26      │ 30      │ 34      │ 29.9    │ 2.17  │ 26      │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼───────┼─────────┤
│ Bytes/Sec │ 5.43 kB │ 5.43 kB │ 6.27 kB │ 7.11 kB │ 6.25 kB │ 453 B │ 5.43 kB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴───────┴─────────┘

Req/Bytes counts sampled once per second.

299 requests in 10.07s, 62.5 kB read

结果为：

• 10 秒总共发送了 299 请求
• 每个请求平均被处理的时间是 328.59 ms
• 平均每秒能够处理的请求是 29.9 个，TPS 等于：29.9

根据结果可以发现，这个接口有很大的处理空间。由于 nodejs 运行环境为单线程，如果遇到密集的 CPU 运行，则会导致主线程卡死，等待处理结果。所以我们应该在进行负载测试的时候，进行性能监测，最好能够了解每个调用栈的 CPU 使用情况，针对性进行优化。