首先，介紹下背景，我使用的系統是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引數真實結果）

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 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！