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壓力測試有關的參數說明
- -n 1000：代表這一次的整體測試執行中，總共會發出1000個連線。
- -c 100：代表這一次的整體測試執行中，每一次壓測作業，同時間會併行使用100條連線。
- 承上「-n 1000 -c 100」，也就是說總共會循換做10次，每次100個連線，總共會發出1000個連線壓測。
有關於ab.exe壓力測試有關的回應說明
- Server Software: Web主機的作業系統與版本（若Web主機設定關閉此資訊則無）
- 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: 平均每秒可回應多少要求
- Time per request: 平均每個要求所花費的時間（單位: 豪秒）
- Time per request: 平均每個要求所花費的時間，跨所有同時連線數的平均值（單位: 豪秒）
- Transfer rate: 從壓測主機到WebServer之間的網路傳輸速度
Connection Times（ms）／壓力測試時的連線處理時間，詳細意義如下：
橫軸：
- min: 最小值
- mean: 平均值（正、負標準差）
- median: 平均值（中間值）
- max: 最大值
縱軸：
- Connect: 從壓測主機發出TCP要求到Web主機，所花費的建立時間
- Processing: 從TCP連線建立後，直到HTTP回應的資料全部都收到，所花的時間
- Waiting: 從發送HTTP要求完後，到HTTP回應第一個Byte，所等待的時間
- 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）試著修正看看。