Apache Benchmark安装、参数含义&使用总结、结果分析

首先，介绍下背景，我使用的系统是CentOS7.1。

 

Apache Benchmark简称AB，安装有两种方式：

1.使用sudo yum install httpd-tools 命令安装（比较简单便捷，我使用的是此种方式）。

2.下载Apache的源码，编译安装（感兴趣的可以试试这种方式）。

参数含义&使用总结：

本节内容大多源引自：http://blog.miniasp.com/post/2008/06/30/Using-ApacheBench-ab-to-to-Web-stress-test.aspx

经常使用的参数如下：

1.同时10个连线，连续点击10000（每个Request执行完成后都会自动断线，然后再重新连线）（疑问：每次等10个都返回结果了，在同时发起10个访问？）

2.同时10个连线，连续点击10000，并且使用Keep-Alive方式连线（当Web Server支持Keep-Alive功能时Apache Benchmark会在同一个连线下连续点击该网页）

注：根据我的使用经验，发现使用-k参数后，系统的QPS就会急剧的下降，不知道是哪些地方设置有问题还是怎么回事儿？

3.将测试中的某些数据输出到output.csv文件中

注：参数-e和-g均会生成一个数据文件，但内部的数据的含义，以及有什么价值，现在还体会不到。

4.参数-r很有必要说下，在我使用ab时发现-n 不超过5000的情况下，-c可以任意设置（小于-n的参数即可）都没有问题，但是当-n的参数设置大于5000，同时-c参数大于200时总是返回如下图的错误：（注：以上数据只是个约数，但通常在这些数字附近就会出现错误）

针对这个问题，网上的解决办法基本一致，但我试了以后还是不能解决我的问题（注：解决办法参见转载的这篇文章）。

最后发现使用参数-r即可解决这个问题，但是如下图中的Failed requests就会有很多。（注：此图只是说明，并不是高并发，大访问量情况下使用-r参数真实结果）

关于Failed requests这个参数即括号中四个参数的解释，可参见网页：http://blog.miniasp.com/post/2009/10/07/Explain-ApacheBench-ab-for-the-Failed-request-field.aspx

5.设定测试时间

此例的含义为：并发访问数为3，持续访问时间为5分钟（300秒）

结果分析：

压力测试的核心在于：在可靠的数据的前提下进行结果分析。下面结合一次测试的结果来说明每个结果数据所代表的意义。其中相比较更重要的数据项为：

Failed requests、Requests per second和Time per request。其中Failed Requests的数量太高的话，很有可能代表你的Web Application的稳定度不够，而导致大量请求无法响应；Request per second代表每秒可以处理的请求数，即代表Web Application的承载量有多少（在不考虑带宽限制的情况下）。

例子如下：

下面具体解释下各个参数的含义：

• Server Software:    Web主機的作業系統與版本(若Web主機設定關閉此資訊則無)；在此例中就是压力测试的对象nginx
• Server Hostname:  Web主機的IP位址(Hostname)
• Server Port:           Web主機的連接埠(Port)
• Document Path:     測試網址的路徑部分
• Document Length: 測試網頁回應的網頁大小
• Concurrency Level: 同時進行壓力測試的人數
• Time taken for tests: 本次壓力測試所花費的總秒數                                                  ；此次压力测试花费的世间
• Complete requests: 完成的要求數(Requests)
• Failed requests:      失敗的要求數(Requests)
• Write errors:           寫入失敗的數量
• Total transferred:   本次壓力測試的總數據傳輸量(包括 HTTP Header 的資料也計算在內)
• HTML transferred:  本次壓力測試的總數據傳輸量(僅計算回傳的 HTML 的資料)
• Requests per second: 平均每秒可回應多少要求                                                     ；是否可以认为是QPS
• Time per request:  平均每個要求所花費的時間(單位: 豪秒)                                    ；每次并发请求时间（所有并发）
• Time per request:  平均每個要求所花費的時間，跨所有同時連線數的平均值(單位: 豪秒)    ；每一次请求时间（并发平均）
• Transfer rate:         從 ab 到 Web Server 之間的網路傳輸速度

最後的 Connection Times (ms) 指的是壓力測試時的連線處理時間：

橫軸欄位的部分：

• min:       最小值
• mean:    平均值(正、負標準差)
• median: 平均值(中間值)
• max:      最大值

縱軸欄位的部分：

• Connect:     從 ab 發出 TCP 要求到 Web 主機所花費的建立時間。
• Processing:  從 TCP 連線建立後，直到 HTTP 回應(Response)的資料全部都收到所花的時間。
• Waiting:       從發送 HTTP 要求完後，到 HTTP 回應(Response)第一個 Byte 所等待的時間。
• Total:           等於 Connect + Processing 的時間（因為 Waiting 包含在 Processing 時間內了）

壓力測試的基本觀念

• 排除頻寬的限制
  • 做壓力測試通常不會考量「頻寬的限制」，所以一般來說不會將測試的主機擺在遠端機房、然後測試程式擺在公司內部的主機，而是會將壓力測試的 Client 跟 Web 主機擺在同一個網段下進行壓力測試。
  • 因為「頻寬」只要花錢就會有了，但是主機的承載量卻是有限的，從遠端進行壓力測試主要的限制是在「頻寬」而非「效能」，所以從遠端單點進行壓力測試毫無任何意義可言，這樣是測不出主機的效能極限的。
  • 如果你有能力與資源進行大規模（多點）壓力測試的話，透過遠端進行壓力測試才有意義。
• 壓力要循序漸進
  • 你不要一下字就執行同時連線數 100 人，而是要循序漸進的慢慢加同時連線數上去，才不會讓 Web Application 一下字承受過大的負載而導致效能的數據不正確（例如說 Failed requests 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！