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