Apache Bench壓力測試平行要求數的增加與相關知識

今天在Windows 7下進行Apache Bench（ab.exe）時候，發現一個很詭異的問題，就是-c參數（concurrency）的調整，永遠不能夠大於64，也就是說，你一調整到65就會丟出錯誤給你。

例如像這個錯誤：

apr_pollset_create failed: Invalid argument (22)

翻遍網路，只有一兩篇在講這個事情，而且會把解決方案導向到叫你去改Windows Registry，去regedit一些HTTP Connection Max相關的東西，我只能說，千萬不要，因為根本就沒有用！

真實的答案很簡單，就是你的ab.exe是舊版本（This is ApacheBench, Version 2.0.41），沒錯，就是這麼簡單，換新版的就好了。請到Apache基金會官方網站下載，解出裡面的ab.exe（This is ApacheBench, Version 2.3）就可以用了。

懶得下載的人，請點選這裡服用：ab.exe Download!

//於是你就可以大方的下指令了！Success!!
ab -n 1000 -c 100 http://www.google.com/

有關於ab.exe壓力測試有關的參數說明

  1. -n 1000：代表這一次的整體測試執行中，總共會發出1000個連線。
  2. -c 100：代表這一次的整體測試執行中，每一次壓測作業，同時間會併行使用100條連線。
  3. 承上「-n 1000 -c 100」，也就是說總共會循換做10次，每次100個連線，總共會發出1000個連線壓測。

有關於ab.exe壓力測試有關的回應說明

  1. Server Software: Web主機的作業系統與版本（若Web主機設定關閉此資訊則無）
  2. Server Hostname: Web主機的IP位址（Hostname）
  3. Server Port: Web主機的連接埠（Port）
  4. Document Path: 測試網址的路徑部分
  5. Document Length: 測試網頁回應的網頁大小
  6. Concurrency Level: 同時進行壓力測試的人數
  7. Time taken for tests: 本次壓力測試所花費的總秒數
  8. Complete requests: 完成的要求數（Requests）
  9. Failed requests: 失敗的要求數（Requests）
  10. Write errors: 寫入失敗的數量
  11. Total transferred: 本次壓力測試的總數據傳輸量（包括 HTTP Header 的資料也計算在內）
  12. HTML transferred: 本次壓力測試的總數據傳輸量（僅計算回傳的 HTML 的資料）
  13. Requests per second: 平均每秒可回應多少要求
  14. Time per request: 平均每個要求所花費的時間（單位: 豪秒）
  15. Time per request: 平均每個要求所花費的時間，跨所有同時連線數的平均值（單位: 豪秒）
  16. Transfer rate: 從壓測主機到WebServer之間的網路傳輸速度

Connection Times（ms）／壓力測試時的連線處理時間，詳細意義如下：

橫軸：

  1. min: 最小值
  2. mean: 平均值（正、負標準差）
  3. median: 平均值（中間值）
  4. max: 最大值

縱軸：

  1. Connect: 從壓測主機發出TCP要求到Web主機，所花費的建立時間
  2. Processing: 從TCP連線建立後，直到HTTP回應的資料全部都收到，所花的時間
  3. Waiting: 從發送HTTP要求完後，到HTTP回應第一個Byte，所等待的時間
  4. Total: 等於「Connect + Processing」的時間（因為Waiting已經包含在Processing內了）

有關於ab.exe壓力測試有關Failed requests的說明

在壓力測試的結果中，常常會有那種爆棚式的錯誤數據跑出來，如果你的測試是落在動態網頁（ASP.NET、PHP、JSP...）的運行範疇內，那其實這樣的結果並不用太驚訝，請看下面這個WTF等級的例子：

	Complete requests: 1000
	Failed requests:    990 (Connect: 0, Length: 990, Exceptions: 0)

甚麼，送出一千次的要求，竟然有九百九十次的錯誤，網站再怎麼爛也不可能是這樣的錯誤法吧？別緊張請觀察一下是不是都是Length方面的錯誤，如果是的話，可以嘗試下列這樣解釋。

基本上，ab會把第一次收到的Response資料，記錄其Header的Content-Length數據，假設這個內容的長度是X。當你第2次～第1000次要求若跟這個X資料長度不一樣時，ab就會將其認列並記載在Failed requests的Length的計數器當中。

請基於上面的運作原理來解釋你的錯誤問題，如果你的壓測網址，該頁面會亂數回應你長度不一的訊息畫面（例如亂數模擬不同的身分登入操作），那麼這個Failed requests你完全可以忽略不計。如果你的壓測網址，該頁面永遠會固定回應給你一個靜態畫面（例如永遠模擬同一個身分登入進行操作），那這個Failed requests你或許就要再多琢磨看看了。

若在壓測時期，出現有關於apr_poll: The timeout specified has expired (70007)的錯誤：這個錯誤「有可能」是你的伺服器覺得壓力來源端開太多，因此試圖阻擋所致。要排除這個問題的話，不妨在指令列裡面添加「-k」參數（Use HTTP KeepAlive feature）試著修正看看。

ApacheBench Concurrency Maximum 64 Increase Command FailedRequests