| 导语日常运营做活动会带来很大的请求量，为了评估当前系统是否能支撑住预估的请求量，那么就对访问量大的接口做压测，一般会进行多轮压测，主要是排查系统隐藏的bug和发现可以优化的点，然后根据压测结果评估当前系统负载，然后准备扩容等工作，使系统能稳定可靠的支撑运营活动。

压测术语说明

1. 吞吐率

概念：服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。计算公式：总请求数 / 处理完成这些请求数所花费的时间，即 Request per second = Complete requests / Time taken for tests

2. 并发连接数

概念：某个时刻服务器所接受的请求数目

3. 并发用户数

概念：要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。

4.用户平均请求等待时间

计算公式：处理完成所有请求数所花费的时间/ （总请求数 / 并发用户数），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level）

以上是我们压测关心的一些指标，其中吞吐率是我们最关心的指标。

1. 压测工具ab实践

ab用法介绍

这里介绍常用的参数和用法

-n requests 总请求数
-c concurrency 一次产生的请求数，可以理解为并发数
-t timelimit 测试所进行的最大秒数, 可以当做请求的超时时间
-p postfile 包含了需要POST的数据的文件
-T content-type POST数据所使用的Content-type头信息

get请求：ab -n 1000 -c 10 -t 10 "https://testurl.com/get_user?uid=133&token=xxx"

post请求：ab -n 1000 -c 10 -t 10 -p post.json -T "application/x-www-form-urlencoded" "https://testurl.com/add_user" 其中post.json是你的那个接口需要的json参数

{"name":"bob","age":12,"sex":1}

编写脚本批量压测接口(多个同时同时压测)

在实际压测中，我们往往要压测很多接口，而很多接口都有同时请求的情况，所以我们不能单独一个一个测接口得到TPS，所以需要自己编写脚本，去完成同时压测的要求。以下是写的一个简单的批量压测脚本test.sh：

#!/bin/sh

RESULT_DIR="/data/home/yawenxu/TestResult/"
jsonFileArr="ff0e_00.json ff0e_02.json ff0e_05.json ff0e_06.json ff0e_07.json ff0e_08.json ff0e_10.json ff0e_11.json" # 每个接口post需要的json参数的文件
concurrency=${1-1} #并发数
count=${2-1}  #总请求数
input_file_name=$3
exec_single_ab(){
        if [ -f $1 ];then
                /usr/bin/ab -n $2 -c $3 -p $1 -T "application/x-www-form-urlencoded" "http://$4" >$RESULT_DIR$1$2"_nginx.txt" 2>&1 &
        else
                echo $1" is not exists"
        fi

}
exec_loop_ab(){
        for item_name in $jsonFileArr
        do
                exec_single_ab $item_name $concurrency $count "http://api.com/xxx" &
        done
}

if [ -f $input_file_name ];then
        exec_single_ab $input_file_name $concurrency $count &
else
        exec_loop_ab &
fi

这个脚本保证了多个接口同时压测，同时将每个接口的压测报告保存到文件里，便于分析。执行命令sh test.sh 10000 10000 一次性生成压测报告文件如下：

ff0e_00.json10000_nginx.txt  ff0e_05.json10000_nginx.txt  ff0e_07.json10000_nginx.txt  ff0e_10.json10000_nginx.txt
ff0e_02.json10000_nginx.txt  ff0e_06.json10000_nginx.txt  ff0e_08.json10000_nginx.txt  ff0e_11.json10000_nginx.txt

某个文件的压测报告如下图

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

Benchmarking www.voovlive.com (be patienComCompleted 100 requesComCompleted 200 requesComCompleted 300 requesComCompleted 400 requesCompleted 500 requests
Finished 500 requests


Server Software:        
Server Hostname:        10.228.15.46
Server Port:            3002

Document Path:          /test/get
Document Length:        248 bytes

Concurrency Level:      500
Time taken for tests:   2.523 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      161500 bytes
Total POSTed:           359640
HTML transferred:       124000 bytes
Requests per second:    198.19 [#/sec] (mean)
Time per request:       2522.808 [ms] (mean)
Time per request:       5.046 [ms] (mean, across all concurrent requests)
Transfer rate:          62.52 [Kbytes/sec] received
                        139.21 kb/s sent
                        201.73 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   13   4.1     14      17
Processing:   416  948 516.2    828    2485
Waiting:      415  947 516.4    827    2485
Total:        432  961 513.2    841    2497

Percentage of the requests served within a certain time (ms)
  50%    841
  66%    913
  75%    990
  80%   1213
  90%   2039
  95%   2064
  98%   2476
  99%   2484
 100%   2497 (longest request)
uest)

我们比较关心的几个点 1.Concurrency Level: 500 // 并发数 2.Time taken for tests: 2.523 seconds // 总花费时间 3.Complete requests: 500 // 完成请求数 4.Failed requests: 0 // 失败请求数 5.Requests per second: 198.19 [#/sec] (mean) // 吞吐率（TPS） 6.Time per request: 2522.808 [ms] (mean) // 一个请求花费的平均时间 7.Percentage of the requests served within a certain time (ms) // 请求的时间分布情况压测主要是评估当前系统的负载，所以一般看看吞吐率(TPS)和成功率就够了，如果想评估接口性能，可以查看第6和第7项数据。往往需要改变压测参数(并发数和总请求数)多压测几次，才会得到准确的TPS。

问题总结

ab优点如下：

1. 简单易用
2. 支持post请求，接受json文件作为参数 （方便编写脚本批量测试）
3. 压测量不大的情况下够用(1024个并发以下)

但是也有一些明显缺点

1. 无法持续时间压测，控制速度压测。ab没有这个功能。

2. 压测量起不来。主要是ab只能利用单个cpu，只能是单进程，而系统限制每个进程打开的最大文件数为1024，所以最多1024个线程，如果是多核cpu，就浪费了这些资源。

3. 如果中途的请求被服务器拒绝了，测试报告不完整，无法得出已完成请求的压测情况。以下是中途被服务器拒绝的报告，很不友好:

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

Benchmarking 100.125.176.120 (be patienCompleted 100 requests
Completed 200 requests
ComCompleted 300 requesComCompleted 400 requesComCompleted 500 requesapr_socket_recv: Connection timed out (110)
Total of 536 requests completed
ed

2.压测工具wrk实践

发现ab的这些缺点，无法满足目前的压测要求之后，去查看了很多压测工具，最后发现了wrk这个同样易用，没有上面ab的缺点，使用学习成本稍高一点的压测工具。 wrk负载测试时可以运行在一个或者多核CPU，wrk结合了可伸缩的事件通知系统epoll和kqueue等多线程设计思想。

wrk用法介绍

1. 安装

压测是在测试环境的机器上进行的，由于测试环境机器访问不了外网所以安装一些工具较为麻烦。为什么要到测试环境机器上进行呢？因为

1. 本机windows环境，安装同样比较麻烦
2. 压测现网服务有些是通过ip压测的，本机无法访问。
3. 测试环境机器性能比较高，并发请求量更大一些。

安装步骤如下

下载安装包到本地源码地址
本地上传压缩包到测试环境机器
在测试环境解压，编译，如果编译报错，少了一些依赖库，按照同样的步骤安装。

2. 主要参数说明

-t --threads   开启的线程数，用于控制并发请求速度。最大值一般是cpu总核心数的2-4倍
-c --conections 保持的连接数（会话数）
-d --duration 压测持续时间(s)
-s --script 加载lua脚本（post请求写一些参数到脚本里）
-H --header 在请求头部添加一些参数
--latency 压测报告输出请求回包花费时间分布
--timeout 请求的最大超时时间(s),这个很有用

简单的例子 wrk -t4 -c1000 -d30s -T30s --latency http://www.baidu.com 上面这条命令的意思是用4个线程来模拟1000个并发连接，整个测试持续30秒，连接超时30秒，打印出请求的延迟统计信息。

编写脚本批量压测接口(多个接口同时压测)

1.编写lua脚本因为接口需要json格式参数，所以首先编写lua脚本，在lua脚本里添加json参数, ff0e_05.lua如下

request = function()
    local headers = { }
    headers['Content-Type'] = "application/json"
    body = '{"uin":"123","lang":"en"}'
    return wrk.format('POST', nil, headers, body)
end

编写压测脚本一个简单的批量压测脚本test.sh：

#!/bin/sh

RESULT_DIR="/data/home/yawenxu/wrkTestResult/"
luaFileArr="ff0e_00.lua ff0e_02.lua ff0e_05.lua ff0e_06.lua ff0e_07.lua ff0e_08.lua ff0e_10.lua ff0e_11.lua" # 每个接口post需要的json参数的lua文件
concurrency=${1-1} #开启线程数，用于控制速度
count=${2-1}  #保持连接数
continueTime=${3-1}  # 持续时间
input_file_name=$4
exec_single_wrk(){
        if [ -f $1 ];then
                ./wrk -t $2 -c $3 -d $continueTime --script=$1 --latency --timeout 10 "http://$4" >$RESULT_DIR$1$3"_nginx.txt" 2>&1 &
        else
                echo $1" is not exists"
        fi
}

exec_loop_wrk(){
        for item_name in $luaFileArr
        do
                exec_single_wrk $item_name $concurrency $count "http://api.com/xxx" &
        done
}

if [ -f $input_file_name ];then
        exec_single_wrk $input_file_name $concurrency $count &
else
        exec_loop_wrk &
fi

这个脚本保证了多个接口同时压测，同时将每个接口的压测报告保存到文件里，便于分析。执行命令sh test.sh 12 5000 10 会一次性生成所有接口的压测报告文件，其中一份压测报告如下:

Running 10s test @ http://api.com/xxx
  12 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.27s   386.53ms   1.99s    59.87%
    Req/Sec    53.85     75.74   777.00     93.91%
  Latency Distribution
     50%    1.26s
     75%    1.61s
     90%    1.80s
     99%    1.97s
  3641 requests in 10.10s, 1.88MB read
  Socket errors: connect 0, read 0, write 0, timeout 2146
Requests/sec:    360.51
Transfer/sec:    190.82KB

看上面的报告，可以看出保持连接数5000，持续压测10s，超时时间10s，这种情况接口超时情况特别严重，总请求数3641超时数目2146，但是查看 Latency Distribution又发现99%的请求都在1.97s内回包，这个时候就要考虑nginx接入层的转发能力是不是比较低导致的。所以我们可以压测下我们服务的具体ip，不通过nginx接入层。最后压测发现的确是nginx流量转发有评价瓶颈，那我们可以采取扩容nginx的措施。

在做脚本压测的同时，需要实时查看现网服务的cpu使用率和系统负载情况，发现cpu使用率和负载明显飙升。命令:top -d 1，可以参考使用 Perf 和火焰图分析 CPU 性能

问题总结

压测不能做单独接口的压测，必须模拟实际情况，对实际有同时请求的很多接口同时压测，这样才能发现系统的问题
压测需要考虑多方面因素。

1. 压测所用机器的性能，每秒发出的请求数能不能达到预估值
2. 压测工具每秒发出的请求数能不能达到预估值，以及能不能持续压测。
3. 压测现网服务，需要考虑到依赖的其他服务，比如接入层(nginx)自身的处理能力，可以对接入层做压测。
4. 压测的时候需要实时查看现网服务的cpu使用率和系统负载情况，这个可以发现编码上的bug。

本文首发在掘金转载请注明原作者，如果你觉得这篇文章对你有帮助或启发，也可以来请我喝咖啡。利益相关：本篇文章所有涉及到的软件均为笔者日常所用工具，无任何广告费用。