apache ab命令 参数/结果释义

释义"/>

apache ab命令 参数/结果释义

使用apache ab命令测试性能

ab -n 10000 -c 10000 -p "post.txt" -H "accept: */*" -H "Authorization: ae776a-2cc5-4f83-9e28-39524823c757" -T "application/x-www-form-urlencoded" "http://192.168.1.91:8080/app/api/getJson"

http://192.168.241.129/

ab -n 1000 -c 100 -p "post.txt" -H "accept: */*" -H "Authorization: ae776a-2cc5-4f83-9e28-39524823c757" -T "application/x-www-form-urlencoded" "http://192.168.241.129:8080/app/public/appLogin?password=admin123&username=admin"

参数释义 总共请求1000次 一次请求100个 post文件 请求头信息 地址

下面我们对这些参数，进行相关说明。如下：-n在测试会话中所执行的请求个数。默认时，仅执行一个请求。-c一次产生的请求个数。默认是一次一个。-t测试所进行的最大秒数。其内部隐含值是-n 50000，它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。-p包含了需要POST的数据的文件。-P对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。-T POST数据所使用的Content-type头信息。-v设置显示信息的详细程度-4或更大值会显示头信息，3或更大值可以显示响应代码(404,200等),2或更大值可以显示警告和其他信息。-V显示版本号并退出。-w以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。-i执行HEAD请求，而不是GET。-x设置<table>属性的字符串。-X对请求使用代理服务器。-y设置<tr>属性的字符串。-z设置<td>属性的字符串。-C对请求附加一个Cookie:行。其典型形式是name=value的一个参数对，此参数可以重复。-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标记可以抑制这些信息。
————————————————
版权声明：本文为CSDN博主「ZhaoYingChao88」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：

执行结果

C:\phpstudy_pro\Extensions\Apache2.4.39\bin>ab -n 10000 -c 10000 -p "post.txt" -H "accept: */*" -H "Authorization: ae776a-2cc5-4f83-9e28-39524823c757" -T "application/x-www-form-urlencoded" "http://192.168.241.129:8080/app/api/getJson"
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, /
Licensed to The Apache Software Foundation,  192.168.241.129 (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 requestsServer Software:
Server Hostname:        192.168.241.129
Server Port:            8080Document Path:          /app/api/getJson
Document Length:        42 bytesConcurrency Level:      10000
Time taken for tests:   9.724 seconds
Complete requests:      10000
Failed requests:        9909(Connect: 0, Receive: 0, Length: 9909, Exceptions: 0)
Total transferred:      703913 bytes
Total body sent:        2230000
HTML transferred:       3822 bytes
Requests per second:    1028.39 [#/sec] (mean)
Time per request:       9723.959 [ms] (mean)
Time per request:       0.972 [ms] (mean, across all concurrent requests)
Transfer rate:          70.69 [Kbytes/sec] received223.96 kb/s sent294.65 kb/s totalConnection Times (ms)min  mean[+/-sd] median   max
Connect:        0    1  17.3      0    1002
Processing:  1215 5194 2167.7   5496    8819
Waiting:       27 4667 2401.7   5041    8617
Total:       1221 5194 2167.7   5497    8819Percentage of the requests served within a certain time (ms)50%   549766%   638075%   681580%   707590%   849495%   866598%   877499%   8803100%   8819 (longest request)

解释如下:

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：下面这里说的靠谱：

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:

1. apr_time_t start, /* Start of connection */

2. connect, /* Connected, start writing */

3. endwrite, /* Request written */

4. beginread, /* First byte of input */

5. done; /* Connection closed */

And when request is done some timings are stored as:

1. s->starttime = c->start;

2. s->ctime = ap_max(0, c->connect - c->start);

3. s->time = ap_max(0, c->done - c->start);

4. 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:

1. t1: Start of connection

2. t2: Connected, start writing

3. t3: Request written

4. t4: First byte of input

5. t5: Connection closed

Then the definitions would be:

1. Connect: t1-t2 Most typically the network latency

2. Processing: t2-t5 Time to receive full response after connection was opened

3. Waiting: t3-t4 Time-to-first-byte after the request was sent

4. Total time: t1-t5

update: 

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

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

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

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

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