當gu只有1個worker，我理解他沒有併發能力，所有的請求都是順序執行的。
所以 http_load -parallel 1 -fetches 1000 url 和 http_load -parallel 100 -fetches 1000 url 的總耗時是一樣的，如果gu有併發能力,-parallel 100總耗時應該減少。為了方便說明，我這樣對比測試：
gu只有1 worker，用ab壓，1000個請求，分別-c1和-c100
1個併發:
qps:603.40
平均耗時(time per request):1.657ms
總耗時(time taken for tests):1.65s
100個併發:
qps:608.63
平均耗時(time per request):164.302ms
總耗時(time taken for tests):1.64s
當ab -n1000 -c100時，ab實際上是每次100個併發，分成10次完成1000個請求。這裡的平均耗時164ms是每批次100個request全部完成後的耗 時，gu實際在執行時是順序執行的，所以約等於1.65ms*100，http_load的測試結果和ab類似，1000個請求,分別 -parallel1和-parallel100
1個併發:
qps:609.40
平均耗時(msecs/first-response): 1.647ms
總耗時:1.647s
100個併發:
qps:654.534
平均耗時(time per request):145.154ms
總耗時:1.527s
gu有8 worker時,再用ab壓，同樣是1000個請求，分別-c1和-c100
1個併發:
qps:544
平均耗時(time per request):1.83ms
總耗時(time taken for tests):1.85s
100個併發:
qps:4317
平均耗時(time per request):23.16ms
總耗時(time taken for tests): 0.23s
可以發現這次單個請求耗時沒有變化(因為**本身需要這麼多時間來執行)，但100個併發時，總耗時降低到只有0.23s,原因是100 個併發請求基本被同時處理，所以只有10個順序執行的'批次'，大大減少了總耗時。每批次耗時是23ms，總體qps提公升到了4317。 http_load的測試結果和ab是類似的。
單個請求:
qps:483.187
平均耗時(msecs/first-response):1.83ms
總耗時:2.0s
100個併發:
qps:4287
平均耗時(msecs/first-response):20.5ms
總耗時:0.23s
好了，前面碼了這麼多字，其實我想說明的是，當-parallel增加時，qps也期望能提公升，這個點現在是 -parallel=10，qps就無法提公升了，如果再增加-parallel，msecs/first-response也隨之增加，吞吐量無法再提 高。比如 http_load -parallel 200 -fetches 1000 urllist 時msecs/first-response會增加一倍，達到41.95ms。
當然這裡的測試是純cpu消耗的，所以併發提公升有限，我之前的detail頁面，平均耗時200ms，但這裡有mysql,cache等 外部消耗時間，真正的cpu占用其實沒有200ms，當乙個request過來時，如果cpu在等待io，gu應該能智慧型的切換去處理另外乙個 request，但現在貌似它在傻傻的wait，是我配置有問題嗎？
使用ab對頁面進行壓力測試
ab是apache自帶的乙個很好用的壓力測試工具，當安裝完apache的時候，就可以在bin下面找到ab 1 我們可以模擬100個併發使用者，對乙個頁面傳送1000個請求 ab n1000 c100 其中 n代表請求數，c代表併發數 返回結果 首先是apache的版本資訊 this is apach...
使用ab對tornado進行壓力測試
ab使用命令 ab c 20 n 1000 http localhost 8000 c 併發數 n 請求總數 測試環境 1g記憶體，單cpu單核，虛擬機器ubuntu 測試結果 server software tornadoserver 5.0.2 server hostname localhost...
用AB對Webservice做壓力測試
ab工具介紹見 web壓力測試工具 使用以下命令測試webservice ab c 100 n 1000 p zip.txt v 10 t text xml charset utf 8 http localhost mywebservice zipcode.asmx?op call注 c 併發請求數...