今天在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/
Connection Times(ms)/壓力測試時的連線處理時間,詳細意義如下:
橫軸:
縱軸:
在壓力測試的結果中,常常會有那種爆棚式的錯誤數據跑出來,如果你的測試是落在動態網頁(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