ab压力测试

需要清楚的是，ab进行一切测试的本质都是基于HTTP，所以可以说它是对于Web服务器软件的黑盒性能测试，它获得的一切数据和计算结果，都可以通过HTTP来解释。

另有一些压力测试软件，包括LoadRnner、Jmeter等，则是不同程度上包含了服务器处理之外的时间，比如LoadRunner运行在用户PC上，可以录制浏览器行为，这种测试的结果玩玩侧重于站点用户的角度，有另外一些层面的参考意义。

请看下面的命令行信息：

请注意我们在启动ab时，传入3个命令行参数，它们正是代表了前面提到的前提条件：

-n1000 表示总请求数位1000

-c 表示并发用户数为10

http://localhost/index.html 表示这些请求的目标URL。

测试结果一目了然，我们看到吞吐率显示为2204.64reqs/s。同时，在测试结果中还有一些其他内容也值得我们关注，主要包括：

Server Software

表示被测试的Web服务器软件名称，这里是Apache/2.2.19,它来自于http响应数据的头信息，所以如果是我们自己编写的Web服务器软或者修改开源Web服务器软件的源代码，便可以随意改写这里的名称。

vi /usr/local/apache/conf/httpd.conf #隐藏具体版本信息

ServerSignature Off

ServerTokens Prod

Server Hostname

表示请求的URL中的主机部分名称，它来自于http请求数据的头信息，这里我们请求的URL是http://localhost/index.html,所以主机名为localhost，说明我们的请求是从Web服务器端发起的。

Server Port

表示被测试的Web服务器软件的监听端口，为了方便测试，我们后面会对多个不同的Web服务器软件使用不同的监听端口。

Document Path

表示请求的URL中根绝对路径，它同样来自于http请求数据的头信息，通过它的后缀名，我们一般可以理解该请求的类型。

Document Length

表示http响应数据的正文长度。

Concurrency Level

表示并发用户数，这是我们设置的参数。

Time taken for tests

表示所有这些请求被处理完成花费的总时间。顺便提一下，某些Apache版本如2.2.4附带的ab，对于这一统计项存在一些计算上的bug，当总请求数较少时，其统计的总时间会无法小于0.1s。

Complete requests

表示总请求数，这是我们设置的相应参数。

Failed requests

表示失败的请求数，这里的失败是指请求的连接服务器、发送数据、接收数据等环节发生异常，以及无响应后超时的情况。对于超时时间的设置可以用ab的-t参数。

而如果接受到的http响应数据的头信息中含有2xx以外的状态码，则会在测试结果显示另一个名为“Non-2xx responses”的统计项，用于统计这部分请求数，这些请求并不算是失败的请求。

Total transferred

表示所有请求的响应数据长度总和，包括每个http响应数据的头信息和正文数据的长度。注意这里不包括http请求数据的长度，所以Total

transferred代表了从Web服务器流向用户PC的应用层数据总长度。通过使用ab的-v参数即可查看详细的http头信息。

HTML transferred

表示所有请求的响应数据中正文数据的总和，也就是减去了Total transferred中http响应数据中头信息的长度。

Requests per second

这便是我们重点关注的吞吐率，它等于：

Complete requests / Time taken for tests

Time per request

这便是前面提到的用户平均请求等待时间，它等于:

Time taken for tests / (Complete requests /Concurrency Level)

Time per request?(across all concurrent requests)

这便是前面提到的服务器平均请求处理时间，它等于：

Time taken for tests / Complete requests

这正是吞吐率的倒数。同时，它也等于：

Time per request / Concurrency Level

Transfer rate

表示这些请求在单位时间内从服务器获取的数据长度，它等于：

Total transferred / Time taken for tests

这个统计项可以很好的说明服务器在处理能力达到限制时，其出口带宽的需求量。

利用前面介绍的有关带宽的知识，不难计算出结果。

Percentage of the requests served within a certain time(ms)

这部分数据用于描述每个请求处理时间的分布情况，比如在以上测试结果中，80%请求的处理时间都不超过1ms，而99%的请求都不超过2ms。注意这里的处理时间，是指前面的Time per request，即对于单个用户而言，平均每个请求处理的时间。

继续压力测试

下面，我们再来进行一次压力测试，此时并发用户数为100，其他条件不变，测试结果如下所示：

和前一次的测试结果相比，可以看出，当并发用户数据从原来的10变为100后，吞吐率从原来的2204.64增长到了2711.45，服务器平均请求处理

时间从原来的0.454ms降到了0.369ms，而用户评价请求等待时间从原来的4.536ms增加到了36.881ms.

可见，随着并发用户数的变化，吞吐率、用户平均请求等待时间、服务器配件请求处理时间都发生了相应的变化。

本文转自 linuxpp 51CTO博客，原文链接：http://blog.51cto.com/1439337369/1787985，如需转载请自行联系原作者