背景

小A：小B，最近调你的接口老是超时呀，8秒都还没返回结果，是不是有性能问题呀！
小B ：我看看~~

类似这样的对话，在现实中是时有发生的，不是特别严重的话，往往大家也不会去重视这个事。

尤其是在一些测试资源并不完备的，开发人员对性能测试没有接触过的一些公司，遇到这些会显得更加力不从心。

本着对自己写出来的东西负责，上线之前，我们都应该对自己的接口进行一个简单的压力测试。

其实做这一步也是为了让我们心里有个度，有个底，不至于说连能承受多少量都不知道。如果什么都不知道，那很容易陷入一个无底深渊，这是一件很可怕的事情。

老黄平时用的比较多的是Apache Bench，当然，jmeter、wrk和vegeta也都是非常不错的。

说说用这个的原因吧，免安装，绿色版，开箱(解压)即用，说白了，老黄其实就是懒鬼~~

jmeter要装jdk，懒得弄。

wrk/wrk2 要自己编译，mac上面可以直接安装，但是我的mac配置不高，不折腾。

vegeta用起来感觉不是很顺手，后面再慢慢挖掘。

Apache Bench 介绍

Apache Bench 是Apache服务器自带的一个web压力测试工具，简称ab。

ab是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问，因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标，但是没有图形化结果，不能监控。

ab进行的测试的本质是基于HTTP协议，可以理解为对web服务器软件的黑盒性能测试，获得的一切数据和计算结果，都是可以通过HTTP来解释的。

Apache Bench 简单使用

下面的示例都是在CentOS上面的。

通过下面的命令安装，

yum -y install httpd-tools

装好之后，运行一下ab -V就可以看到版本信息。

ab -VThis is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

运行一下ab -h就可以看到帮助信息。

帮助信息有很多，也比较详细，老黄把一些常用的参数都添加了注释，方便大家查看。

其中最常用的两个参数是 -c 和 -n，当然如果是POST/PUT请求的话，还离不开 -T 和 -p。

说了不少废话，来看看怎么使用才是重点。

下面准备了两个简单的接口来进行演示

[ApiController]
[Route("test")]
public class TestController : ControllerBase
{[HttpGet]public string Get() => "GET";[HttpPost]public string Post([FromBody]string value) => value;
}

这个接口是跑在docker里面的(一台2c4g的活动云服务器)，下面的图可以看到具体的信息，还有两个接口的访问详情。

先来压一下GET请求的接口， 200并发，5000个请求。

ab -c 200 -n 5000 localhost:9000/test

POST请求有点不一样，要先准备一下body的参数，这里在/tmp目录创建了一个post.json文件，里面就一个字符串。

cat /tmp/post.json
"Post"

在压测命令里面，指定Content-Type为application/json， 参数的数据文件路径是/tmp/post.json

同样也是200并发，5000个请求。

ab -c 200 -n 5000 -T "application/json" -p /tmp/post.json localhost:9000/test

到这里，大家对怎么压测，应该都不会太陌生了，比较陌生的应该是压测的结果要怎么看。

下面拿其中一个结果示例来说明各项指标的含义：

Server Software:        Kestrel  # 服务器软件名称
Server Hostname:        localhost  # 服务器主机名
Server Port:            9000  # 服务器端口Document Path:          /test  # 测试的URL路径
Document Length:        3 bytes  # 文档大小Concurrency Level:      200  # 并发数
Time taken for tests:   2.386 seconds  # 消耗的总时间
Complete requests:      5000  # 总次数
Failed requests:        0  # 失败的请求数
Write errors:           0  # 网络连接写入错误数
Total transferred:      680000 bytes  # 传输的总数据量
HTML transferred:       15000 bytes  # HTML文档的总数据量
Requests per second:    2095.43 [#/sec] (mean)  # (平均每秒的请求数) 这个是非常重要的参数数值，服务器的吞吐量
Time per request:       95.446 [ms] (mean)  # (所有并发用户都请求一次的平均时间)
Time per request:       0.477 [ms] (mean, across all concurrent requests)  # (单个用户请求一次的平均时间)
Transfer rate:          278.30 [Kbytes/sec] received   # 每秒获取的数据长度 (传输速率，单位：KB/s)# 网络上消耗的时间的分解
Connection Times (ms)min  mean[+/-sd] median   max
Connect:        0    3   3.7      2      20
Processing:    12   68 120.0     53    1057
Waiting:        1   67 120.1     52    1050
Total:         15   71 119.8     55    1058# 整个场景中所有请求的响应情况
Percentage of the requests served within a certain time (ms)50%     5566%     6375%     6880%     7190%     7795%     8898%    10599%   1012100%   1058 (longest request)

这么多的指标，我们可以重点关注下面几个

1. Requests per second

2. Failed requests

3. 90%，95%和98%的响应时间

第一个是吞吐量，这个上不去，其实是挺尴尬的。

第二个是失败的请求数，这个数要尽可能的低，最好是0，没有失败的。设想一下，100个请求，80个都是失败的，这个结果还能有意义不。

第三个是响应时间，这个可以看到大部分请求的速度如何。

进行压测时的一些小建议：

• 压测尽可能让并发数从低往高慢慢递增，避免一开始就设的太大，一个比较好的参考依据是现在阶段线上环境的并发数

• 压测的持续时间可以持续久一点，这样可以看到更多可能出现的情况，可以考虑5分钟，8分钟，15分钟等

• 有条件的，压测和被压测的机器要独立，因为压测的时候也会有资源占用，可能会影响被压测的接口

• 不要只看压测的结果数据，还要留意被压测机的cpu，内存等指标在压测时是否正常

• 内网压测的效果达到预期后，再考虑外网的，网络因素，可控性不强

分布式压测和全链路压测，暂时不用想了，留给更专业的人去做吧~~