ab压力测试工具

一、概念介绍

吞吐率（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 $\color{red}{//被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。}$
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 $\color{red}{ //总共传输的数据量，指的是ab从被测服务器接收到的总数据量，包括index.html的文本内容和请求头信息。}$
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 　 $\color{red}{//网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。要确定该值是不是瓶}$
$\color{red}{颈，需要了解客户端和被测服务器之间的网络情况，包括网络带宽和网卡速度等信息。}$

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）。