一、簡介：
介紹：
apache自帶的apache Benchmark工具可以用來做壓力測試。
文件位置：
Apache安裝目錄/bin/ab.exe
查看版本：
ab -V可以查看當前ab的版本
二、使用
用處：
可以創建很多的併發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問
常用命令：
ab [可選的參數選項] 需要進行壓力測試的url
例如：ab -c 500 -n 1000 url:端口/path
-c+測試的併發線程數（500個用戶併發），-n總共發起的請求數（總共訪問1000次）
三、結果解析
1. 比較重要的指標是
Requests per second: 122.12 [#/sec] (mean)
相當於 LR 中的 每秒事務數 ，後面括號中的 mean 表示這是一個平均值
Time per request: 8188.731 [ms] (mean)
相當於 LR 中的 平均事務響應時間
2. 最後的百分比代表整個場景中所有請求的響應情況，其中50%的用戶請求響應時間在269ms內，以此類推。
四、附錄：參數一覽
-n即requests，用於指定壓力測試總共的執行次數。
-c即concurrency，用於指定壓力測試的併發數。
-t即timelimit，等待響應的最大時間(單位：秒)。
-b即windowsize，TCP發送/接收的緩衝大小(單位：字節)。
-p即postfile，發送POST請求時需要上傳的文件，此外還必須設置-T參數。
-u即putfile，發送PUT請求時需要上傳的文件，此外還必須設置-T參數。
-T即content-type，用於設置Content-Type請求頭信息，例如：application/x-www-form-urlencoded，默認值爲text/plain。
-v即verbosity，指定打印幫助信息的冗餘級別。
-w以HTML表格形式打印結果。
-i使用HEAD請求代替GET請求。
-x插入字符串作爲table標籤的屬性。
-y插入字符串作爲tr標籤的屬性。
-z插入字符串作爲td標籤的屬性。
-C添加cookie信息，例如："Apache=1234"(可以重複該參數選項以添加多個)。
-H添加任意的請求頭，例如："Accept-Encoding: gzip"，請求頭將會添加在現有的多個請求頭之後(可以重複該參數選項以添加多個)。
-A添加一個基本的網絡認證信息，用戶名和密碼之間用英文冒號隔開。
-X指定使用的代理服務器和端口號，例如:"126.10.10.3:88"。
-V打印版本號並退出。
-k使用HTTP的KeepAlive特性。
使用HTTP的KeepAlive特性。
-k使用HTTP的KeepAlive特性。
-d不顯示百分比。
-S不顯示預估和警告信息。
-g輸出結果信息到gnuplot格式的文件中。
-e輸出結果信息到CSV格式的文件中。
-r指定接收到錯誤信息時不退出程序。
-h顯示用法信息，其實就是ab -help。
--------------------- 作者：NNnora 來源：CSDN 原文：https://blog.csdn.net/NNnora/article/details/80529657?utm_source=copy 版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！
性能測試得到的最重要的指標就是QPS(Requests per second)，反映了接口的併發承受能力，也就是系統的峯值性能。如果對接口的調用超過了這一限制，就要考慮提升硬件或者做一些優化了。
下面具體解釋下各個參數的含義：
- 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 過高），但這只是建議，你也可以一下子操死你的主機，反正你在測主機的極限嘛！
--------------------- 作者：一座青山 來源：CSDN 原文：https://blog.csdn.net/sangyongjia/article/details/49093945?utm_source=copy 版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！