linux ApacheBench

格式： ./ab [options] [http://]hostname[:port]/path
参数：
-n requests Number of requests to perform
//在测试会话中所执行的请求个数。默认时，仅执行一个请求
-c concurrency Number of multiple requests to make
//一次产生的请求个数。默认是一次一个。
-t timelimit Seconds to max. wait for responses
//测试所进行的最大秒数。其内部隐含值是-n 50000。它可以使对服务器的测试限制在一个固定的总时间以内。默认时，没有时间限制。
-p postfile File containing data to POST
//包含了需要POST的数据的文件.
-T content-type Content-type header for POSTing
//POST数据所使用的Content-type头信息。
-v verbosity How much troubleshooting info to print
//设置显示信息的详细程度 - 4或更大值会显示头信息， 3或更大值可以显示响应代码(404, 200等), 2或更大值可以显示警告和其他信息。 -V 显示版本号并退出。
-w Print out results in HTML tables
//以HTML表的格式输出结果。默认时，它是白色背景的两列宽度的一张表。
-i Use HEAD instead of GET
// 执行HEAD请求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 对请求附加一个Cookie:行。 其典型形式是name=value的一个参数对。此参数可以重复。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 对一个中转代理提供BASIC认证信任。用户名和密码由一个:隔开，并以base64编码形式发送。无论服务器是否需要(即, 是否发送了401认证需求代码)，此字符串都会被发送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
//-attributes 设置 属性的字符串. 缺陷程序中有各种静态声明的固定长度的缓冲区。另外，对命令行参数、服务器的响应头和其他外部输入的解析也很简单，这可能会有不良后果。它没有完整地实现 HTTP/1.x; 仅接受某些'预想'的响应格式。 strstr(3)的频繁使用可能会带来性能问题，即, 你可能是在测试ab而不是服务器的性能。

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://127.0.0.1/index.php

这个表示同时处理1000个请求并运行1000次index.php文件.
#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software: Apache/2.0.54
//平台apache 版本2.0.54
Server Hostname: 127.0.0.1
//服务器主机名
Server Port: 80
//服务器端口

Document Path: /index.html.zh-cn.gb2312
//测试的页面文档
Document Length: 1018 bytes
//文档大小

Concurrency Level: 1000
//并发数
Time taken for tests: 8.188731 seconds
//整个测试持续的时间
Complete requests: 1000
//完成的请求数量
Failed requests: 0
//失败的请求数量
Write errors: 0

Total transferred: 1361581 bytes
//整个场景中的网络传输量
HTML transferred: 1055666 bytes
//整个场景中的HTML内容传输量
Requests per second: 122.12 [#/sec] (mean)
//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request: 8188.731 [ms] (mean)
//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request: 8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate: 162.30 [Kbytes/sec] received
//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 646 1078.7 89 3291
Processing: 165 992 493.1 938 4712
Waiting: 118 934 480.6 882 4554
Total: 813 1638 1338.9 1093 7785
//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50% 1093
66% 1247
75% 1373
80% 1493
90% 4061
95% 4398
98% 5608
99% 7368
100% 7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒

由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数



ab -n 3000 -c 15 'http://127.0.0.1/s.do'
Concurrency Level:      15
Time taken for tests:   380.118 seconds
Complete requests:      3000
Failed requests:        37
   (Connect: 0, Receive: 0, Length: 37, Exceptions: 0)
Write errors:           0
Non-2xx responses:      37
Total transferred:      71390473 bytes
HTML transferred:       70481208 bytes
Requests per second:    7.89 [#/sec] (mean)
Time per request:       1900.591 [ms] (mean)
Time per request:       126.706 [ms] (mean, across all concurrent requests)
Transfer rate:          183.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:   813 1725 5397.1   1122   50002
Waiting:      813 1725 5397.1   1122   50002
Total:        813 1725 5397.1   1122   50002

Percentage of the requests served within a certain time (ms)
  50%   1122
  66%   1124
  75%   1134
  80%   1223
  90%   1227
  95%   1408
  98%   1732
  99%  50000
100%  50002 (longest request)


我最近在用 ab ( ApacheBench ) 測試一個網站時發現結果報告中一直會出現 Failed requests，而且出現的次數非常高，我原本以為是壓力測試的結果有大部分是失敗的，但看觀看其他數據卻一點也不覺得有失敗，經過一番研究後才真正理解為何會出現 Failed request 數據。

如下壓力測試的結果：


Server Software:        Microsoft-IIS/7.5
Server Hostname:        example.com
Server Port:            80

Document Path:          /
Document Length:        35137 bytes

Concurrency Level:      1
Time taken for tests:   4.619462 seconds
Complete requests:      100
Failed requests:        99
   (Connect: 0, Length: 99, Exceptions: 0)
Write errors:           0
Keep-Alive requests:    100
Total transferred:      3543782 bytes
HTML transferred:       3507782 bytes
Requests per second:    21.65 [#/sec] (mean)
Time per request:       46.195 [ms] (mean)
Time per request:       46.195 [ms] (mean, across all concurrent requests)
Transfer rate:          749.00 [Kbytes/sec] received




先分析上述數據，我取得的第一份 HTML 文件得到的大小 ( Document Length ) 為 35,137 bytes，我總共發出要求共 100 次 ( Complete requests )，總 HTML 數據傳輸量 ( HTML transferred ) 為 3,507,782 bytes 感覺非常合理，實際的傳輸量大約是單一文件的 100 倍，所以我研判這 100 個 Request 的確有正確送出，但為何 Failed requests 會出現有 99 次的錯誤呢？

只要出現 Failed requests 就會多出現一行要求失敗的各原因的數據統計，分別有 Connect, Length, 與 Exception 三種，分別代表的意義為：

Connect 無法送出要求、目標主機連接失敗、要求的過程中連線被中斷
Length 回應的內容長度不一致 ( 以 Content-Length 標頭值為判斷依據 )
Exception 發生無法預期的錯誤
而從上述說明就可以很明顯看出所有的 Failed requests 都落在 Length 這個類別上，原來這是因為受測網站的首頁是動態的內容，當第一次發出 HTTP request 與後續發出的 HTTP request 所得到回應的 HTML 長度都是不同大小的 ( 每次回應的 Content-Length 大小不一致 )，才會引發 Failed requests 的 Length 問題的失敗，因此這類 Length 不一致的失敗在進行「動態網頁」壓力測試時是合理的，可以不予理會。

這裡的 Length 是以 "第 1 次" 取得的 Content-Length 為主，如果第 2 次以後的 HTTP Request 所得到的 HTTP Response Header 得到的 Content-Length 與第 1 次取得的長度不一致，就會得到 Length 的錯誤。