基于Apache下ab工具进行网站压力性能测试

网站性能压力测试是服务器网站性能调优过程中必不可缺少的一环。只有让服务器处在高压情况下，才能真正体现出软件、硬件等各种设置不当所暴露出的问题。

性能测试工具目前最常见的有以下几种：ab、http_load、webbench、siege。今天我们专门来介绍ab。

1、Apache Bench是什么(简称ab)

Apache Bench 是 Apache 服务器自带的一个web压力测试工具，简称ab。ab也是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一个URL地址进行访问，因此可以用来测试目标服务器的负载压力。总体来说，ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标；但是缺点就是没有图形化结果，不能监控。

2、ab原理

ab命令会创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问。它的测试目标是基于URL的，因此，既可以用来测试Apache的网站访问负载压力，也可以测试nginx、lighthttp、tomcat、IIS等其它Web类型服务器的压力。 ab命令对发出负载的计算机要求很低，既不会占用很高CPU，也不会占用很多内存，但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也须注意，否则一次上太多的负载，可能造成目标服务器因资源耗完，严重时甚至导致死机。

3、ab的安装

可以使用yum安装httpd服务，其中就包含了ab测试工具

也可以yum安装ab的依赖包 apr-util，然后再安装httpd-tools，这样就可以使用ab测试工具了。输入ab -V可以查看当前版本信息

4、ab参数说明

ab 的用法是：ab [options] [http://]hostname[:port]/path

下面我们对这些参数，进行相关说明。如下：

//在测试会话中所执行的总请求个数。默认时，仅执行一个请求。

-n requests Number of requests to perform

//一次产生的请求个数或并发数。默认是一次一个。

-c concurrency Number of multiple requests to make

//测试所进行的最大秒数。其内部隐含值是-n 50000，它可以使对服务器的测试限制在一个固定的总时间以内。默认没有时间限制。

-t timelimit Seconds to max. wait for responses

//抛出异常继续执行测试任务

-r Don’t exit on socket receive error

//包含了需要POST的数据的文件，文件格式如“p1=1&p2=2”.使用方法是 -p 111.txt

-p postfile File containing data to POST

//POST数据所使用的Content-type头信息，如 -T “application/x-www-form-urlencoded” 。（配合-p）

-T content-type Content-type header for POSTing

//设置显示信息的详细程度，-4或更大值会显示头信息，3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。-V显示版本号并退出。

-v verbosity How much troubleshooting info to print

//以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。

-w Print out results in HTML tables

//cookie-name=value，对请求附加一个Cookie：行。其典型形式是name=value的一个参数对，此参数可以重复，用逗号分割。可以借助session实现原理传递 JSESSIONID参数， 实现保持会话的功能，如-C ” c1=1234,c2=2,c3=3,JSESSIONID=FF056CD16DA9D71CB131C1D56F0319F8″

-C attribute Add cookie, eg. -C “c1=1234,c2=2,c3=3” (repeatable)

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

-A对服务器提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即,是否发送了401认证需求代码)，此字符串都会被发送。

-h显示使用方法。

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

-e产生一个以逗号分隔的(CSV)文件，其中包含了处理每个相应百分比的请求所需要(从1%到100%)的相应百分比的(以微妙为单位)时间。由于这种格式已经“二进制化”，所以比’gnuplot’格式更有用。

-g把所有测试结果写入一个’gnuplot’或者TSV(以Tab分隔的)文件。此文件可以方便地导入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行为标题。

-i执行HEAD请求，而不是GET。

-k启用HTTP KeepAlive功能，即在一个HTTP会话中执行多个请求。默认时，不启用KeepAlive功能。

-q如果处理的请求数大于150，ab每处理大约10%或者100个请求时，会在stderr输出一个进度计数。此-q标记可以抑制这些信息。

5、ab性能指标

[root@localhost ~]# ab -n 100 -c 10

http://www.baidu.com/index.html

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

www.baidu.com

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

Server Software: BWS/1.1 //被测试的服务器所用的软件信息，这里使用的是百度自己开发的反向代理Baidu Front End,类似nginx。表示被测试的Web服务器软件名称，如:Apache/2.2.19,它来自于http响应数据的头信息，所以如果是我们自己编写的Web服务器软或者修改开源Web服务器软件的源代码，便可以随意改写这里的名称。
vi /usr/local/apache/conf/httpd.conf #隐藏具体版本信息ServerSignature Off ServerTokens Prod

Server Hostname:

www.baidu.com

//被测主机名。表示请求的URL中的主机部分名称，它来自于http请求数据的头信息

Server Port: 80 //被测主机的服务端口号，一般http请求的默认端口号是80，https默认使用443端口，表示被测试的Web服务器软件的监听端口，为了方便测试，我们后面会对多个不同的Web服务器软件使用不同的监听端口。

Document Path: /index.html //请求的具体文件，表示请求的URL中根绝对路径，它同样来自于http请求数据的头信息，通过它的后缀名，我们一般可以理解该请求的类型。

Document Length: 355034 bytes //请求的文件index.html大小，表示http响应数据的正文长度。

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

Time taken for tests: 3.847 seconds //本次测试总共花费的时间，某些Apache版本如2.2.4附带的ab，对于这一统计项存在一些计算上的bug，当总请求数较少时，其统计的总时间会无法小于0.1s。

Complete requests: 100 //本次测试总共发起的请求数量，可以设置-n参数指定的数量

Failed requests: 96 //失败的请求数量。这里的失败是指请求的连接服务器、发送数据、接收数据等环节发生异常，以及无响应后超时的情况因网络原因，发起的请求并不一定全部成功，通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考。
(Connect: 0, Receive: 0, Length: 96, Exceptions: 0)
而如果接收到的http响应数据的头信息中含有2xx以外的状态码，则会在测试结果显示另一个名为“Non-2xx responses”的统计项，用于统计这部分请求数，这些请求并不算是失败的请求。

Write errors: 0
Total transferred: 35721638 bytes //总共传输的数据量，指的是ab从被测服务器接收到的总数据量，包括index.html的文本内容和请求头信息。注意这里不包括http请求数据的长度，所以Total transferred代表了从Web服务器流向用户PC的应用层数据总长度。通过使用ab的-v参数即可查看详细的http头信息。

HTML transferred: 35604479 bytes //从服务器接收到的index.html文件的总大小，等于Document Length＊Complete requests。表示所有请求的响应数据中正文数据的总和，也就是减去了Total

Requests per second: 25.99 [#/sec] (mean) //平均(mean)每秒完成的请求数：QPS，这是一个平均值，等于Complete requests/Time taken for tests=100/3.847=25.99。这便是我们重点关注的【吞吐率】，要清楚吞吐率是与并发数相关的，即使请求总数相同，但如果并发数不一样，吞吐率还是很可能有很大差异的。它等于：Complete requests / Time taken for tests

Time per request: 384.723 [ms] (mean) //从用户角度看，完成一个请求所需要的时间（因用户数量不止一个，服务器完成10个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍。）这便是前面提到的用户平均请求等待时间，也就是一次并发总的时间。它等于:Time taken for tests / (Complete requests /Concurrency Level)

Time per request: 38.472 [ms] (mean, across all concurrent requests) //服务器完成一个请求的时间。它等于：Time taken for tests / Complete requests 这正是吞吐率的倒数。同时，它也等于：Time per request / Concurrency Level;也可以这么统计：Time per request / Concurrency Level

Transfer rate: 9067.41 [Kbytes/sec] received //网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。要确定该值是不是瓶颈，需要了解客户端和被测服务器之间的网络情况，包括网络带宽和网卡速度等信息。它等于：Total transferred / Time taken for tests。这个统计项可以很好的说明服务器在处理能力达到限制时，其出口带宽的需求量。利用有关带宽的知识，不难计算出结果。

Connection Times (ms)
min mean [+/-sd] median max
Connect: 4 49 174.1 20 1041
Processing: 66 315 348.8 217 2779
Waiting: 6 34 50.5 25 286
Total: 70 364 394.2 237 2790

//这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络连接（Connect），系统处理（Processing）和等待（Waiting）三个部分。表中min表示最小值；mean表示平均值；[+/-sd]表示标准差（Standard Deviation） ，也称均方差（mean square error），这个概念在中学的数学课上学过，表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max当然就是表示最大值了。

//需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了2790ms，这个数据可以在下面的表中得到验证

Percentage of the requests served within a certain time (ms)
50% 237
66% 316
75% 431
80% 462
90% 603
95% 1143
98% 1859
99% 2790
100% 2790 (longest request)

//这个表第一行表示有50%的请求都是在237ms内完成的，可以看到这个值是比较接近平均系统响应时间（第一个Time per request: 384.723[ms] (mean)）

以此类推，90%的请求是小于等于603ms的。刚才我们看到响应时间最长的那个请求是2790ms，那么显然所有请求（100%）的时间都是小于等于2790毫秒的，也就是表中最后一行的数据肯定是时间最长的那个请求（longest request）。这部分数据用于描述每个请求处理时间的分布情况，比如在以上测试结果中，80%请求的处理时间都不超过462ms，而99%的请求都不超过2790ms。注意这里的处理时间，是指前面的Time per request，即对于单个用户而言，平均每个请求处理的时间。

6、ab实际使用

现在用Apache来进行实际操作

cat /etc/httpd/conf/httpd.conf |grep -v ^# |grep -v ^$

mkdir -p /www/baidu.com
echo

'<?php phpinfo();?>'>/

www/baidu.com/index.php
cat /www/baidu.com/index.php

然后启动Apache，访问主机baidu.com
wget

http://baidu.com

然后我们用Apache来测试一下。输入命令
ab -n 100 -c 10

http://baidu.com/index.php

7、测试nginx性能

上面我们用Apache进行了测试，接下来我们再进行Nginx的性能测试
输入 rpm -Uvh

http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

yum install -y nginx

cat /etc/nginx/conf.d/default.conf |grep -v ^# |grep -v ^$

mkdir -p /www/nginx.cn
echo

'<?php phpinfo();?>'>/

www/nginx.cn/index.php
cat /www/nginx.cn/index.php

wget nginx.cn

ab -n 100 -c 10

http://nginx.cn/index.php

通过上图，测试结果也一目了然，nginx测试出的吞吐率为：Requests per second: 91.10 [#/sec] (mean)，对比apache请求该页面的吞吐率，发现nginx吞吐率比apache高。

可以利用ab完成不复杂的性能测试，或者比较适用于单一URL的测试
ab判断成功与否只通过2xx的状态码作为依据，不接收服务器的返回值，但lr却接收服务器完整的返回。所以在同样的响应时间下，ab测试支持的并发数会大于lr，tps也会大于lr。
ab运行并发的时候和所在运行机器上的cpu颗数有关，越多则并发越大。所以在linux下支持的并发大于在Windows下