介紹
wrk是一款簡單的HTTP壓測工具,託管在Github上,https://github.com/wg/wrk.
wrk 的一個很好的特性就是能用很少的線程壓出很大的併發量. 原因是它使用了一些操作系統特定的高性能 io 機制, 比如 select, epoll, kqueue 等. 其實它是複用了 redis 的 ae 異步事件驅動框架. 確切的說 ae 事件驅動框架並不是 redis 發明的, 它來至於 Tcl的解釋器 jim, 這個小巧高效的框架, 因爲被 redis 採用而更多的被大家所熟知.
安裝
git clone https://github.com/wg/wrk.git
cd wrk
make
使用
wrk -t12 -c100 -d30s http://www.baidu.com
返回:
Running 30s test @ http://www.baidu.com
12 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 300.59ms 210.80ms 1.99s 87.17%
Req/Sec 28.25 15.33 121.00 68.12%
10036 requests in 30.10s, 149.22MB read
Socket errors: connect 0, read 29, write 0, timeout 24
Requests/sec: 333.47
Transfer/sec: 4.96MB
參數解釋:
參數解釋:
12 threads and 100 connections
:
總共是12個線程,100個連接(不是一個線程對應一個連接)
latency
和Req/Sec
:
代表單個線程的統計數據,latency
代表延遲時間,Req/Sec
代表單個線程每秒完成的請求數,他們都具有平均值, 標準偏差, 最大值, 正負一個標準差佔比。一般我們來說我們主要關注平均值和最大值. 標準差如果太大說明樣本本身離散程度比較高. 有可能系統性能波動很大.
10036 requests in 30.10s, 149.22MB read
在30秒之內總共有10036
個請求,總共讀取149.22MB
的數據
Socket errors: connect 0, read 29, write 0, timeout 24
總共有29個讀錯誤,24個超時.
Requests/sec和Transfer/sec
所有線程平均每秒鐘完成了333.47個請求,每秒鐘讀取4.96MB數據量
如果想看看響應時間的分佈,可以增加--latency
:
wrk -t12 -c100 -d30s --latency http://www.baidu.com
Running 30s test @ http://www.baidu.com
12 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 401.52ms 270.05ms 1.98s 91.39%
Req/Sec 21.04 10.87 60.00 56.44%
Latency Distribution
50% 307.72ms
75% 317.86ms
90% 616.33ms
99% 1.66s
7487 requests in 30.10s, 111.42MB read
Socket errors: connect 0, read 4, write 0, timeout 55
Requests/sec: 248.70
Transfer/sec: 3.70MB