Question

通常在上线前会对这些小流量环境进行预估流量的压测，来预估目前的小流量集群服务器能否承载对应的流量，进而评估一下使用多少服务器集群部署服务，才能足够承载流量，又不至于浪费服务器资源。

基于本地服务压测，对于实际上线，需要先部署在测试服务器，然后对测试环境内网域名进行压测，进而判断能否承受预估的 QPS，从而对服务集群进行扩容等操作。

WebBench

WebBench 是一个在 Linux 下使用的非常简单的网站压测工具。它使用 fork() 模拟多个客户端同时访问设定的 URL，测试网站在压力下工作的性能，最多可以模拟 3 万个并发连接去测试网站的负载能力。

WebBench 不能支持 Windows，只能在 Linux 等类 UNIX 系统下使用。

首先需要安装一下 brew，这是一个针对 macOS 和 Linux 的包管理工具，安装完在终端里直接输入 brew 看下有没有正常输出即可。

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

然后装一下 wget，它是 Linux 下的一个安装文件的工具，对应的安装包可以通过它下载下来。

brew install wget

最后来装一下 WebBench。

wget http://www.ha97.com/code/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz // 解压
cd webbench-1.5
make
make install

安装完以后，在终端中输入 WebBench 验证一下。

需要关注的参数有两个：

• -c: 并发量。
• -t: 运行时间。

对服务简单压测试验下看看。

可以看到 200 并发就会出现大规模请求异常的情况，不过这个结果算比较简陋的，加上对环境和安装步骤上相对苛刻一些，所以并不推荐使用这个方案。

wrk

wrk 是一款针对 HTTP 协议的基准测试工具，它能够在单机多核 CPU 的条件下，使用系统自带的高性能 I/O 机制，如 epoll、kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载。

wrk 支持大多数类 UNIX 系统，不支持 Windows。不同的类 UNIX 系统安装方式也略有差异。

装一下 wrk。

brew install wrk

装完可以在终端执行一下 wrk -v 验证一下。

上面执行完以后可以看到它列出了 wrk 相关的参数，其中常用到的有三个参数：

• -c: 保持打开状态的 HTTP 连接总数。
• -d: 测试时长。
• -t: 使用线程。

其中连接数（c）会平分给每个线程，比如设置 -c200 -t8，那么将启用 8 个线程，每个线程处理 200/8 个请求，可以对 bing 搜索简单试验一下，具体参数其实大部分都是一样的。

这个方案更多是给后端同学测吞吐率用的，包括线程等参数，具体的值不好衡量，对前端不算那么友好。

autocannon

一个用 Node 编写的 HTTP/1.1 基准测试工具，受到 wrk 和 wrk2 的极大启发，支持 HTTP 管道和 HTTPS。autocannon 可以产生比 wrk 和 wrk2 更多的负载。

autocannon 可以同时支持 Windows、Mac 和 Linux 的环境，而且作为一个 npm 包，使用上比较符合前端的开发习惯，安装更为方便，使用方式也很轻量。

npm i autocannon -g

它提供了一些参数来对应不同压测指数，常用的有 3 个：

• -c: 要使用的并发连接数。默认值：10。
• -p: 使用流水线请求的数量。默认值：1。
• -d: 运行秒数。默认值：10。

首先测试一下默认值的效果。

autocannon http://127.0.0.1:3000

在这个 10s 的执行过程，如果切回 client 可以看到服务在飞快请求。

最后可以得到这样一个数据。

介绍一下每个指标对应什么，先看每列的指标：

• 2.5% / 50% / 97.5% / 99%：整个过程百分比所对应的值。
• Avg: 平均值。
• Stdev: 标准差。
• Max: 最大值。

对于每行的指标含义是这样的：

• Latency: 耗时（毫秒)。
• Req/Sec: QPS，吞吐量，每秒请求数。
• Bytes/Sec: 每秒请求字节数。

这些指标通常在对具体接口或是页面 case by case 的性能分析中会有使用，服务器资源判定只需要关注请求时间是否过长，或是是否存在大面积报错即可，这里可以看到大部分数值是正常的，也没有报错等信息。

接下来把并发量提高到 200，再来看下效果。

autocannon -c 200 http://127.0.0.1:3000

从数据上看，发现所有的数据都清 0 了，说明在这个并发量下单服务器的计算支撑不下去，最下面的请求数据中也有显示 200 个错误， 200 个超时。

这时候切回 client 的终端可以看到，服务已经崩掉了，没办法承载 200 的并发量，如果业务需要，这时候就需要考虑给服务器集群进行扩容操作了。