Windows环境下使用ApacheBench（ab）进行接口压力测试及参数结果分析
一、本文目的及内容
本文介绍的主要内容是从零开始在windows环境下首次搭建及使用ab进行接口压力测试及数据分析
二、ab是什么？
ApacheBench 是 Apache 服务器自带的一个web压力测试工具，简称ab。ab本身是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问，因此可以用来测试目标服务器的负载压力或者在开发过程中验证接口在不同并发场景下的运行情况，总体来说ab体量小，使用简单。可提供基本的数据分析接口在不同压力下的表现情况。
二、首次使用
1.Apache Bench下载安装
1.首先需要去官网下载Apache服务器，下载地址：官网下载地址，这里我选择的是2.4.51，如下图，下载完成后解压我们能得到一个名为Apache24的文件夹，下一步就是修改一配置文件。
2.修改配置文件（Apache24\conf\httpd.conf），打开这个httpd.conf,修改Define SRVROOT地址为本地实际路径如图，改为Apache24文件夹的实际存放位置，这里需要注意的是建议路径中不要有中文，我在尝试的时候由于路径中有中文，后续服务安装不了，去掉了就可以。
3.管理员身份打开一个命令窗口，切换目录（Apache24\bin），执行命令，插图是我本机，因为已经安装过了
./httpd.exe -k install
4.服务安装完毕后需要启动一下服务，win+R,输入services.msc 回车，找到Apache2.4服务，启动它。
至此环境准备完成。
2.参数详解
打开一个CMD切换目录到（Apache24\bin），执行命令 ./ab.exe -h,会得到如下帮助：
这里简单释义几个参数，各位使用过程中可灵活探索
-n即requests，用于指定压力测试总共的执行次数
-c即concurrency，用于指定压力测试的并发数
-t即timelimit，等待响应的最大时间(单位：秒)（这里我理解的是一个最长基准线时间，而不是timeout那种相应超过最长时间后即断开连接的限制）
-s是timeout,等待相应的最长时间（单位：秒，默认30秒）
-p即postfile，发送POST请求时需要上传的文件，此外还必须设置-T参数
-H添加任意的请求头，例如：“Content-Length: 0”
3.第一次GET请求测试
发起测试命令，这里有一个注意点
这里需要注意的是Complete requests不能小于Concurrency Level（-n 不能小于 -c），具体原因，留个小疑问各位思考尝试一下（尝试一下会有明确异常提示）。
./ab.exe -n 10 -c 2 "http://www.apache.org/"
4.第一次POST请求测试
发起测试命令，post请求稍微有些不同，需要文件内定义请求体，parm.txt,后边跟格式，-H是header参数
./ab.exe -n 10 -c 2 -p F:/Apache24/htdocs/parm.txt -T "application/json" -H "PK:9937" -r "*(此处是地址)"
三、测试结果分析
$ ./ab.exe -n 10 -c 2 "http://www.apache.org/"
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache(被调用的服务器用的软件信息)
Server Hostname: www.apache.org（目标主机名）
Server Port: 80（访问目标端口）
Document Path: /（具体请求路径或者说文件路径）
Document Length: 73488 bytes（请求文件的大小）
Concurrency Level: 2（并发数）
Time taken for tests: 3.140 seconds（此次执行测试调用总耗时）
Complete requests: 10（此次测试总共发起请求次数）
Failed requests: 0 （失败的请求次数）
Total transferred: 739910 bytes （总共传输的数据量，指的是ab从被测服务器接收到的总数据量）
HTML transferred: 734880 bytes （从服务器接收到的html文件的总大小）
Requests per second: 3.18 [#/sec] (mean) （平均(mean)每秒完成的请求数，Complete requests/Time taken for tests，10/3.140=3.18）
Time per request: 628.047 [ms] (mean) （此并发情况下每个用户感觉到的请求时间，也就是说服务器处理一批并发的时间）
Time per request: 314.024 [ms] (mean, across all concurrent requests)（此并发情况下平均每个请求的时间，理论来这个数*并发数应该约等于上一个值）
Transfer rate: 230.10 [Kbytes/sec] received（网络传输速度）
Connection Times (ms)
min mean[+/-sd] median max
Connect: 84 155 72.9 204 236
Processing: 208 385 131.7 456 553
Waiting: 83 173 74.5 213 251
Total: 294 539 203.6 660 789
表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接（Connect），系统处理（Processing）和等待（Waiting）三个部分。表中min表示最小值； mean表示平均值；[+/-sd]表示标准差（Standard Deviation） ，也称均方差（mean square error），这个概念在中学的数学课上学过，表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max当然就是表示最大值了。
需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了789ms，这个数据可以在下面的表中得到验证。
Percentage of the requests served within a certain time (ms)
50% 660
66% 690
75% 749
80% 753
90% 789
95% 789
98% 789
99% 789
100% 789 (longest request)
这个表第一行表示有50%的请求都是在660ms内完成的，可以看到这个值是比较接*均系统响应时间
以此类推，90%的请求是小于等于789ms的。刚才我们看到响应时间最长的那个请求是789ms，那么显然所有请求（100%）的时间都是小于等于789毫秒的，也就是表中最后一行的数据肯定是时间最长的那个请求（longest request）。
以上，为个人搜集资料实践整理的结果，如有错误还望指正。