阅读 142

ab和wrk接口压测实践

| 导语 日常运营做活动会带来很大的请求量,为了评估当前系统是否能支撑住预估的请求量,那么就对访问量大的接口做压测,一般会进行多轮压测,主要是排查系统隐藏的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 "testurl.com/get_user?ui…"

post请求:ab -n 1000 -c 10 -t 10 -p post.json -T "application/x-www-form-urlencoded" "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. 测试环境机器性能比较高,并发请求量更大一些。
复制代码

安装步骤如下

  1. 下载安装包到本地源码地址
  2. 本地上传压缩包到测试环境机器
  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 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
复制代码
  1. 编写压测脚本 一个简单的批量压测脚本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. 压测需要考虑多方面因素。
1. 压测所用机器的性能,每秒发出的请求数能不能达到预估值
2. 压测工具每秒发出的请求数能不能达到预估值,以及能不能持续压测。
3. 压测现网服务,需要考虑到依赖的其他服务,比如接入层(nginx)自身的处理能力,可以对接入层做压测。
4. 压测的时候需要实时查看现网服务的cpu使用率和系统负载情况,这个可以发现编码上的bug。

复制代码

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

关注下面的标签,发现更多相似文章
评论