一、概念介绍
-
吞吐率(Requests per second)
概念:服务器并发处理能力的量化描述,单位是reqs/s,指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数,称之为最大吞吐率。
计算公式:总请求数 / 处理完成这些请求数所花费的时间,即 Request per second = Complete requests
/ Time taken for tests -
并发连接数(The number of concurrent connections)
概念:某个时刻服务器所接受的请求数目,简单的讲,就是一个会话。 -
并发用户数(The number of concurrent users,Concurrency Level)
概念:要注意区分这个概念和并发连接数之间的区别,一个用户可能同时会产生多个会话,也即连接数。
二、ab工具简介
ab全称为:apache bench
- 官网解释
ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能,主要是显示你安装的Apache每秒可以处理多少个请求。
- 其他网站解释
ab是apache自带的压力测试工具。ab非常实用,它不仅可以对apache服务器进行网站访问压力测试,也可以对或其它类型的服务器进行压力测试。比如nginx、tomcat、IIS等。
三、ab的原理
ab命令会创建多个并发访问线程,模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的,因此,它既可以用来测试apache的负载压力,也可以测试nginx、lighthttp、tomcat、IIS等其它Web服务器的压力。
ab命令对发出负载的计算机要求很低,它既不会占用很高CPU,也不会占用很多内存。但却会给目标服务器造成巨大的负载,其原理类似CC攻击。自己测试使用也需要注意,否则一次上太多的负载。可能造成目标服务器资源耗完,严重时甚至导致死机。
四、参数说明
| 参数 | 说明 |
|---|---|
| 即requests,用于指定压力测试总共的执行次数。 | |
| 即concurrency,用于指定压力测试的并发数。 | |
| -t | 即timelimit,等待响应的最大时间(单位:秒)。 |
| -b | 即windowsize,TCP发送/接收的缓冲大小(单位:字节)。 |
| -p | 即postfile,发送POST请求时需要上传的文件,此外还必须设置-T参数。 |
| -u | 即putfile,发送PUT请求时需要上传的文件,此外还必须设置-T参数。 |
| -T | 即content-type,用于设置Content-Type请求头信息,例如:application/x-www-form-urlencoded,默认值为text/plain。 |
| -v | 即verbosity,指定打印帮助信息的冗余级别。 |
| -w | 以HTML表格形式打印结果。 |
| -i | 使用HEAD请求代替GET请求。 |
| -x | 插入字符串作为table标签的属性。 |
| -y | 插入字符串作为tr标签的属性。 |
| -z | 插入字符串作为td标签的属性。 |
| -C | 添加cookie信息,例如:"Apache=1234"(可以重复该参数选项以添加多个)。 |
| -H | 添加任意的请求头,例如:"Accept-Encoding: gzip",请求头将会添加在现有的多个请求头之后(可以重复该参数选项以添加多个)。 |
| -A | 添加一个基本的网络认证信息,用户名和密码之间用英文冒号隔开。 |
| -P | 添加一个基本的代理认证信息,用户名和密码之间用英文冒号隔开。 |
| -X | 指定使用的代理服务器和端口号,例如:"126.10.10.3:88"。 |
| -V | 打印版本号并退出。 |
| 使用HTTP的KeepAlive特性。 | |
| -d | 不显示百分比。 |
| 后跟秒数,为请求最长等待时间。 | |
| -g | 输出结果信息到gnuplot格式的文件中。 |
| -e | 输出结果信息到CSV格式的文件中。 |
| 指定接收到错误信息时不退出程序。 | |
| -h | 显示用法信息,其实就是ab -help |
举例:
- get请求:
ab -n 30000 -c 2500 -k -r -s 120 -H 'accept: /' -H 'X-Api-Key:cp/nPA7GYotev3itGQEwM52+5zVCrv1e53NlM5ds3JXYmFL86Lkxb7/LffVDK+AmFkUZaaW0JR96asNtypjaQmGW3QxxsT0/OMCHepBJL+C9nM3DLqUa8ch+eRBcYcR0bW76erVOPps828YASVQx+w==' -H 'X-Hos-Id:100' -H 'X-Api-Ver:1.0' http://1.85.45.235:37060/patient/v1/offline/regist/unauth/dept
- post请求:
ab -n 100000 -c 500 -r -k -s 120 -H 'accept: /' -H 'X-Api-Key:cp/nPA7GYotev3itGQEwM52+5zVCrv1e53NlM5ds3JXYmFL86Lkxb7/LffVDK+AmFkUZaaW0JR96asNtypjaQmGW3QxxsT0/OMCHepBJL+C9nM3DLqUa8ch+eRBcYcR0bW76erVOPps828YASVQx+w==' -H 'X-Api-Ver:1.0' -p /home/ctds/abtest/cloudSync1.txt -T application/json http://122.112.188.1:10101/sync/v1/sync/sys_param_business。
其中cloudSync1.txt文件为body体中请求参数的JSON格式。
五、测试结果分析
This is ApacheBench, Version 2.3 <>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
//以上为apache的版本信息,与本次测试无关
Benchmarking www.baidu.com (be patient).....done
//以上内容显示测试完成度,本次测试发起请求数量较少,完成较快,无中间过程显示。在请求数量很多时会分行显示当前完成数量。
Server Software: bfe/1.0.8.14
Server Hostname: www.baidu.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
Document Path: /index.html
Document Length: 227 bytes
Concurrency Level: 10
Time taken for tests: 1.093 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 103314 bytes
HTML transferred: 22700 bytes
Requests per second: 91.50 [#/sec] (mean)
Time per request: 109.287 [ms] (mean)
Time per request: 10.929 [ms] (mean, across all concurrent requests)
Transfer rate: 92.32 [Kbytes/sec] received
Connection Times (ms)
| 参数 | min | mean | [+/-sd] | median | max |
|---|---|---|---|---|---|
| Connect | 47 | 74 | 12.9 | 74 | 106 |
| Processing | 9 | 32 | 20.2 | 32 | 106 |
| Waiting | 9 | 29 | 19.1 | 27 | 98 |
| Total | 66 | 106 | 20.8 | 106 | 195 |
//这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接(Connect),系统处理(Processing)和等待(Waiting)三个部分。表中min表示最小值; mean表示平均值;[+/-sd]表示标准差(Standard Deviation) ,也称均方差(mean square error),这个概念在中学的数学课上学过,表示数据的离散程度,数值越大表示数据越分散,系统响应时间越不稳定。 median表示中位数; max当然就是表示最大值了。
//需要注意的是表中的Total并不等于前三行数据相加,因为前三行的数据并不是在同一个请求中采集到的,可能某个请求的网络延迟最短,但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了195ms,这个数据可以在下面的表中得到验证。
Percentage of the requests served within a certain time (ms)
50% 106
66% 109
75% 111
80% 114
90% 118
95% 154
98% 176
99% 195
100% 195 (longest request)
//这个表第一行表示有50%的请求都是在106ms内完成的,可以看到这个值是比较接近平均系统响应时间(第一个Time per request: 109.287 [ms] (mean) )以此类推,90%的请求是小于等于118ms的。刚才我们看到响应时间最长的那个请求是195ms,那么显然所有请求(100%)的时间都是小于等于195毫秒的,也就是表中最后一行的数据肯定是时间最长的那个请求(longest request)。