【原创】Apache ab结果参数详解

解释如下:

Server Software

服务器软件软件名称。

Server Hostname

被测服务器的主机名。

Server Port

被测试的Web服务器的监听端口。

SSL/TLS Protocol

仅当使用，才会打印。表示客户端和服务器协商的参数。

Document Path

请求URL.

Document Length

第一次成功返回的的文档大小，如果文档长度在测试的时候发生变化，这个响应会被当作错误，因此如果失败的请求下面有Length类型的错误，可以考虑是否是因为被测的url是动态产生的缘故导致返回长度不一致。

Concurrency Level

测试过程中的并发用户数（并发度）

Time taken for tests

完成测试的时间，从socket第一次连接被创建开始，到最后一个响应被接收为止。

Complete requests

成功响应接收的数量。

Failed requests

失败的请求数。如果这个大于0，会在其后打印额外的一行，说明具体失败的详细分类，分别列出连接失败、读取响应失败，不正确的长度或者异常的请求数。读取响应失败可能是服务器来不及处理这些请求，支持的并发连接太少导致连接被关闭，因此没有返回，导致读取响应失败。不正确的长度有可能是正常的，需要进一步分析。连接失败可能就是被测服务器没有启动。异常可能是返回的结果页面中出现的一些异常。这里不统计非2XX的响应码个数，即非2XX码不统计为失败请求。

Write errors

写入请求错误，一般应该不会出现，这算是ab的错误 (broken pipe).

Non-2xx responses

非2XX码的响应结果，如果所有的响应都是2XX，则不会输出

Keep-Alive requests

保持活跃请求的连接数

Total body sent

如果配置了测试过程要发送的数据包，这表示在测试过程总的发送字节数。如果没有数据包发送，这一行不会显示。

Total transferred

表示所有请求的响应数据长度总和，包括每个HTTP响应数据的头信息和正文数据的长度。注意这里不包括HTTP请求数据的长度，仅仅为web服务器流向用户PC的应用层数据总长度。

HTML transferred

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

Requests per second

每秒处理的请求数，即QPS，RPS，TPS。 这个值通过计算：完成的请求数/总消耗时间，得出

Time per request

每个请求花费的时间。第一个为用户请求等待时间：总的时间/总的请求书/并发度。

第二个为服务器请求等待时间为吞吐量的倒数，也可以这么统计：用户请求等待时间/Concurrency Level。

第一个是单个用户的服务质量，第二个是服务器整体的服务质量。

从用户角度来说，第一个公式表明压力测试指定的并发度对单个用户访问服务器性能有影响，并发度越小用户请求等待时间越小，性能越好，用户体验越快、越好。

从服务器的角度来说，第二个公式表明，压力测试指定的并发度越大，每秒发送过来的请求数太多，导致服务器进程/线程切换频繁，执行时间变长，用户等待时间变长，性能下降。但是如果并发度越小，则会造成资源浪费（CPU等）。

综合的来说，就是要找到一个合适的并发度，使得单个用户的质量以及服务器的质量达到一个比较平衡的点

Transfer rate

传输速度，公式为 totalread / 1024 / timetaken

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

　　表示小于某一时间的请求数在全过程中的占比

update 2016年8月10日 16:55:23

Connection Times：下面这里说的靠谱：

http://stackoverflow.com/questions/2820306/definition-of-connect-processing-waiting-in-apache-bench

Connect and Waiting times

The amount of time it took to establish the connection and get the first bits of a response

Processing time

The server response time—i.e., the time it took for the server to process the request and send a reply

Total time

The sum of the Connect and Processing times

I equate this to:

• Connect time: the amount of time it took for the socket to open
• Processing time: first byte + transfer
• Waiting: time till first byte
• Total: Sum of Connect + Processing

2. 以下貌似更靠谱，可以作为上述的补充：即Waiting时间被包含在Processing时间内。

By looking at the source code we find these timing points:

apr_time_t start,           /* Start of connection */
           connect,         /* Connected, start writing */
           endwrite,        /* Request written */
           beginread,       /* First byte of input */
           done;            /* Connection closed */

And when request is done some timings are stored as:

        s->starttime = c->start;
        s->ctime     = ap_max(0, c->connect - c->start);
        s->time      = ap_max(0, c->done - c->start);
        s->waittime  = ap_max(0, c->beginread - c->endwrite);

And the 'Processing time' is later calculated as

s->time - s->ctime;

So if we translate this to a timeline:

t1: Start of connection
t2: Connected, start writing
t3: Request written
t4: First byte of input
t5: Connection closed

Then the definitions would be:

Connect:      t1-t2   Most typically the network latency
Processing:   t2-t5   Time to receive full response after connection was opened
Waiting:      t3-t4   Time-to-first-byte after the request was sent
Total time:   t1-t5

update:

　　通常所说的吞吐量或者rps/tps/qps 是指服务器的处理能力，因为我们一般所测试的所关心的就是服务器的性能。以下用qps来表示。

　　　　qps是单位时间内处理的请求数，平均响应时间是指服务器的处理时间，所以qps和平均响应时间是互为倒数。

　　　　平均等待时间是从请求发出到获取到完整响应的总时间， 这表示用户端的性能，值是：平均响应时间*并发用户数，表示并发用户数越多，同时发送请求过来的总数越大，服务器处理要排队，就算多进程或者多线程来增加性能也是会有排队的情况，总的来说的计算方法就是如此。

　　　　所以一般测试结果的响应时间是指平均等待时间，是指客户端的响应时间，并不是上面所说的平均响应时间！！！！

　　　　所以为了错误理解，测试时，应该直接说响应时间，或者平均用户等待时间，这个是测试工具统计出来的结果。服务器“平均响应时间”应该是服务器处理平均响应时间，平均处理时间，该值不是一个统计值，是通过计算而来。