一直以来我都是用Loadrunner去做性能测试。Loadrunner实际上是一个很重的性能测试工具。他的功能很全面，是一把很好的牛刀。

　　如果我们只是需要对一个页面做简单的性能测试，使用Loadruner这把牛刀就不是一个很好的选择了。

　　所以就找了把小刀－－ab来试试。这把小刀真的是轻巧又锋利，在这里就记录一下对ab测试过程中的一些自己的理解，供大家参考。

　　我们就拿百度首页来祭刀吧。首先你得有一把刀，也就是安装好Apache，网上教程一大堆就不复述了，本文使用MacBook自带的ab命令进行测试。

　　测试场景：模拟10个用户，对百度首页发起总共100次请求。

　　测试命令： ab -n 100 -c 10  www.baidu.com/index.html

　　本文主要针对ab的测试报告进行解析，有关ab的使用方法改天再新开贴交流。

　　测试报告：

　　

下面来逐行解释我的理解，以下注释部分有查阅网上资料，但所写内容均为自己理解之后手打内容，希望加入自己的理解之后能让读者更容易理解。

bogon:~ tang$ ab -n 100 -c 10  www.baidu.com/index.html

This is ApacheBench, Version 2.3 <$Revision: 1706008$>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, www.zeustech.net/

Licensed to The Apache Software Foundation, www.apache.org/

//以上为apache的版本信息，与本次测试无关

Benchmarking www.baidu.com (be patient).....done

//以上内容显示测试完成度，本次测试发起请求数量较少，完成较快，无中间过程显示。在请求数量很多时会分行显示当前完成数量。

 

 

Server Software:        bfe/1.0.8.14    //被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。

Server Hostname:        www.baidu.com //被测主机名

Server Port:            443 //被测主机的服务端口号，一般http请求的默认端口号是80，https默认使用443端口

SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128  //加密协议

 

Document Path:          /index.html  //请求的具体文件

Document Length:        227 bytes   //请求的文件index.html大小

 

Concurrency Level:      10 //并发级别，也就是并发数，请求中－c参数指定的数量

Time taken for tests:   1.093 seconds //本次测试总共花费的时间

Complete requests:      100 //本次测试总共发起的请求数量

Failed requests:        0 //失败的请求数量。因网络原因或服务器性能原因，发起的请求并不一定全部成功，通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考。

Total transferred:      103314 bytes  //总共传输的数据量，指的是ab从被测服务器接收到的总数据量，包括index.html的文本内容和请求头信息。

HTML transferred:       22700 bytes //从服务器接收到的index.html文件的总大小，等于Document Length＊Complete requests＝227 bytes＊100＝22700 bytes

Requests per second:    91.50 [#/sec] (mean) //平均(mean)每秒完成的请求数：QPS，这是一个平均值，等于Complete requests/Time taken for tests=100/1.093=91.50

Time per request:       109.287 [ms] (mean) //从用户角度看，完成一个请求所需要的时间（因用户数量不止一个，服务器完成10个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍。）

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

ab压测

简介

• 做测试或者服务端开发的同学经常想要知道我们的后台服务能同时承载多少用户量，通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。压力测试需要确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这是就需要用到一些压测工具来对服务器进行并发压力测试。常见的压力测试工具有Jmeter，LoadRunner，ab等等，一般来说做压力测试，建议使用Jmeter或者LoadRunner，但是简单场景的压测使用ab就很方便快捷，还可以在linux服务器上进行，可以与其他压测工具做下对比。

本文将介绍如何使用ab对服务器进行压力测试，内容有

• ab工具的安装
• 压测命令的用法
• 压测简单示例
• 压测结果分析

---

1、ab工具的安装

• 介绍

  ab是apachebench命令的缩写，ab命令会创建多个并发访问线程，模拟多个访问者同时对某一HTTP URL地址进行访问。

  ab命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存。但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也需要注意，否则一次上太多的负载。可能造成目标服务器资源耗完，严重时甚至导致死机。

• 安装

yum -y install httpd-tools

• 查看版本

ab -V

2、压测命令的用法

• 参数解析：

-n 测试会话中所执行的请求个数,默认仅执行一个请求,如果不指定-t参数，默认执行完所有请求后自动结束压测

-c 一次产生的请求个数,即同一时间发出多少个请求,默认为一次一个,此参数可以控制对服务器的单位时间内的并发量

-t 测试所进行的最大秒数,默认为无时间限制....其内部隐含值是[-n 50000],它可以使对服务器的测试限制在一个固定的总时间以内,如果时间到了，请求个数还未执行完，也会被停止。

-p 包含了需要POST的数据的文件,数据格式以接口请求参数定义的格式为准,eg. xxx.json
  #json 内容示例： {"name":"小明","sex":"男"}

-T POST 数据所使用的Content-type头信息,指定请求参数格式，eg. application/json

-r 在接口返回失败后，默认会终止压测，添加此参数后压测会继续进行

-v 设置显示信息的详细程度

-w 以HTML表格的形式输出结果,默认是白色背景的两列宽度的一张表

-i 以HTML表格的形式输出结果,默认是白色背景的两列宽度的一张表

-x 设置属性的字符串,此属性被填入[/table]

-y 设置属性的字符串

-z 设置[table]属性的字符串

-C 对请求附加一个Cookie行，其典型形式是name=value的参数对,此参数可以重复

-H 对请求附加额外的头信息,此参数的典型形式是一个有效的头信息行,其中包含了以冒号分隔的字段和值的对(如"Accept-Encoding:zip/zop;8bit")

-A HTTP验证,用冒号:分隔传递用户名及密码

-P 无论服务器是否需要(即是否发送了401认证需求代码),此字符串都会被发送

-X 对请求使用代理服务器

-V 显示版本号并退出

-k 启用HTTP KeepAlive(长连接)功能,即在一个HTTP会话中执行多个请求,默认为不启用KeepAlive功能

-d 不显示"percentage served within XX [ms] table"的消息(为以前的版本提供支持)

-S 不显示中值和标准背离值,且均值和中值为标准背离值的1到2倍时,也不显示警告或出错信息,默认会显示最小值/均值/最大值等(为以前的版本提供支持)

-g 把所有测试结果写入一个'gnuplot'或者TSV(以Tab分隔的)文件

-e 产生一个以逗号分隔的(CSV)文件,其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微秒为单位)时间

-h 显示使用方法

-k 发送keep-alive指令到服务器端

• 一般用法

对某接口进行压力测试:

ab -n 1000000 -c 200 -r  "http://localhost:8080/helloworld?name=小明"

以每秒200个请求的速度对此接口进行访问，知道请求数达到1000000个为止，忽略接口返回的错误信息

3、压测简单示例

• 对get请求进行压测（一些页面和图片资源的访问也可以用这种方式）

#请求接口
ab -n 1000000 -c 200 -r  "http://localhost:8080/helloworld?name=小明" 
#获取图片
ab -n 1000000 -c 200 -r  "http://localhost:8080/static/test.png" 
#获取页面
ab -n 1000000 -c 200 -r  "http://localhost:8080/index.html"

• 对post请求进行压测

#压测命令
ab -n 1000000 -c 1000 -r -p data.json -T 'application/json' "http://localhost:8080/public/regist"

#编辑请求数据
# vi data.json
{
    
"account":"128983321",
"nickname":"小明",
"sex":"男",
"age":22,
"password":"DFKJDFJDLSDKSKL&%DFSD"
}

注意：如果想在请求失败后结束压测，可以去掉-r参数

4、压测结果分析

• 压测命令

  ab -n 10000 -c 1000 -r  "http://127.0.0.1:8080/helloworld?name=小明"
  

• 压测结果

  This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
  Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
  Licensed to The Apache Software Foundation, http://www.apache.org/
  
  Benchmarking 172.25.0.248 (be patient)
  Completed 1000 requests
  Completed 2000 requests
  Completed 3000 requests
  Completed 4000 requests
  Completed 5000 requests
  Completed 6000 requests
  Completed 7000 requests
  Completed 8000 requests
  Completed 9000 requests
  Completed 10000 requests
  Finished 10000 requests
  
  
  Server Software:        
  Server Hostname:        127.0.0.1  #请求的URL主机名
  Server Port:            8080  #请求端口
  
  Document Path:          /helloworld?name=小明  #请求路径
  Document Length:        29 bytes  #HTTP响应数据的正文长度
  
  Concurrency Level:      1000 #并发用户数，这是我们设置的参数之一（-c）
  Time taken for tests:   129.957 seconds  #所有这些请求被处理完成所花费的总时间 单位秒
  Complete requests:      10000  #总请求数量，这是我们设置的参数之一（-n）
  Failed requests:        0      #表示失败的请求数量
  Write errors:           0      #所有请求的响应数据长度总和。包括每个HTTP响应数据的头信息和正文数据的长度
  Total transferred:      1500000 bytes   #所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中HTTP响应数据中的头信息的长度
  
  HTML transferred:       290000 bytes    #吞吐量，计算公式：Complete requests/Time taken for tests  总请求数/处理完成这些请求数所花费的时间
  
  Requests per second:    76.95 [#/sec] (mean)  #用户平均请求等待时间，计算公式：Time token for tests/（Complete requests/Concurrency Level）。处理完成所有请求数所花费的时间/（总请求数/并发用户数）
  
  Time per request:       12995.680 [ms] (mean) #用户平均请求等待时间，计算公式：Time token for tests/（Complete requests/Concurrency Level）。处理完成所有请求数所花费的时间/（总请求数/并发用户数）
  
  Time per request:       12.996 [ms] (mean, across all concurrent requests)  #服务器平均请求等待时间，计算公式：Time taken for tests/Complete requests，正好是吞吐率的倒数。也可以这么统计：Time per request/Concurrency Level
  
  Transfer rate:          11.27 [Kbytes/sec] received  #表示这些请求在单位时间内从服务器获取的数据长度，计算公式：Total trnasferred/ Time taken for tests，这个统计很好的说明服务器的处理能力达到极限时，其出口宽带的需求量。
  
  Connection Times (ms)
                min  mean[+/-sd] median   max
  Connect:        0   24 150.7      0    1003
  Processing:    73 12348 2207.1  12966   13916
  Waiting:       53 12348 2207.1  12966   13916
  Total:         73 12373 2199.0  12968   14023
  
  Percentage of the requests served within a certain time (ms)
    50%  12968 #50%的请求在13秒内返回
    66%  13005 
    75%  13031
    80%  13049
    90%  13109
    95%  13173
    98%  13260
    99%  13350 #99%的请求在13.4秒内返回
   100%  14023 (longest request)