linux下使用ab进行压力测试

首先确定下做压力测试的工具和性能的监控工具，这个压测的工具使用的是ab、监控工具使用的是nmon。

看下linux主机上的ulimit -n 的数据是多少，为改动过的是1024，最好要改的大一点。这个是linux下最大线程数，如果过小的话无法进行大并量的测试。

ab经行压力测试时的脚本我用的形式为：

1.(get方式)./ab -n 1000 -c 1000 -k http://xxx.xxxxx.com/synth/open/recurls.do?test=true

2.(post方式./ab -n 2500 -c 2500 -k -p postfile.ab http://xxx.xxxx.com/synth/open/getTheme.do postfile.ab中为json数据)

其中参数n为请求的次数，c为一次请求的并发次数，-k为keep_alive,一般出现链接被重置的错误时最好带上-k的参数。

还有好多参数，可以在ab–help中看下(这个是超级秘籍)。

结果的每一项的意义就不多说了 在baidu google上一搜一堆的。

领测认为在每一次压测的同时，可以开启nmon进行实时监控，并打开nmon的记录功能进行数据的记录。

Apache附带的ab，它非常容易使用，ab可以直接在Web服务器本地发起测试请求。这至关重要，因为我们希望测试的服务器的处理时间，而不包含数据的网络传输时间以及用户PC本地的计算时间。

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

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

接下来，将使用ab来进行一次压力测试，在本书中我们使用Apache 2.3中附带的ab，其版本信息如下所示：

请看下面的命令行信息：

请注意我们在启动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.
可见，随着并发用户数的变化，吞吐率、用户平均请求等待时间、服务器配件请求处理时间都发生了相应的变化。