轉載地址：http://zjumty.iteye.com/blog/2221040
測試先行是軟件系統質量保證的有效手段. 在單元測試方面, 我們有非常成熟的 xUnit 方案. 在集成測試方面, 我們 selenium 等自動化方案. 在性能測試方面也有很多成熟的工具, 比如 LoadRunner, Jmeter 等. 但是很多工具都是給專門的性能測試人員使用的, 功能雖然強大, 但是安裝和操作不太方便. 作爲開發人員, 我們有些時候想快速驗證我們的解決方案是不是存在性能問題, 或者在併發情況下是否有意想不到的問題. 安裝 LoadRunner 這樣工具, 錄製腳本很麻煩, 用起來就像在用大炮打蚊子.
wrk 是一個很簡單的 http 性能測試工具. 也可以叫做 http benchmark 工具. 只有一個命令行, 就能做很多基本的 http 性能測試.
wrk 的開源的, 代碼在 github 上. https://github.com/wg/wrk
首先要說的一點是: wrk 只能運行在 Unix 類的系統上. 比如 linux, mac, solaris 等. 也只能在這些系統上編譯.
這裏不得不說一下, 爲什麼很多人說 mac 是最好的開發環境. 不是因爲使用 mac 逼格有多高. 而是你可以同時得到 windows 和 linux 的好處. 多數 linux 下的開發工具都可以在 mac 上使用. 很多都是預編譯好的, 有些只需要編譯一下就能用.
wrk 的一個很好的特性就是能用很少的線程壓出很大的併發量. 原因是它使用了一些操作系統特定的高性能 io 機制, 比如 select, epoll, kqueue 等. 其實它是複用了 redis 的 ae 異步事件驅動框架. 確切的說 ae 事件驅動框架並不是 redis 發明的, 它來至於 Tcl的解釋器 jim, 這個小巧高效的框架, 因爲被 redis 採用而更多的被大家所熟知.
要用 wrk, 首先要編譯 wrk.
你的機器上需要已經安裝了 git 和基本的c編譯環境. wrk 本身是用 c 寫的. 代碼很少. 並且沒有使用很多第三方庫. 所以編譯基本不會遇到什麼問題.
git clone https://github.com/wg/wrk.git
cd wrk
make
就 ok了.
make 成功以後在目錄下有一個 wrk 文件. 就是它了. 你可以把這個文件複製到其他目錄, 比如 bin 目錄. 或者就這個目錄下執行.
如果編譯過程中出現:
src/wrk.h:11:25: fatal error: openssl/ssl.h: No such file or directory
#include <openssl/ssl.h>
是因爲系統中沒有安裝openssl的庫.
sudo apt-get install libssl-dev
或
sudo yum install openssl-devel
我們先來做一個簡單的性能測試:
wrk -t12 -c100 -d30s http://www.baidu.com
30秒鐘結束以後可以看到如下輸出:
Running 30s test @ http://www.baidu.com
threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 538.64ms 368.66ms 1.99s 77.33%
Req/Sec 15.62 10.28 80.00 75.35%
requests in 30.09s, 75.28MB read
Socket errors: connect 0, read 5, write 0, timeout 64
Requests/sec: 168.59
Transfer/sec: 2.50MB
先解釋一下輸出:
12 threads and 100 connections
這個能看懂英文的都知道啥意思: 用12個線程模擬100個連接.
對應的參數 -t 和 -c 可以控制這兩個參數.
一般線程數不宜過多. 核數的2到4倍足夠了. 多了反而因爲線程切換過多造成效率降低. 因爲 wrk 不是使用每個連接一個線程的模型, 而是通過異步網絡 io 提升併發量. 所以網絡通信不會阻塞線程執行. 這也是 wrk 可以用很少的線程模擬大量網路連接的原因. 而現在很多性能工具並沒有採用這種方式, 而是採用提高線程數來實現高併發. 所以併發量一旦設的很高, 測試機自身壓力就很大. 測試效果反而下降.
下面是線程統計:
Thread Stats Avg Stdev Max +/- Stdev
Latency 538.64ms 368.66ms 1.99s 77.33%
Req/Sec 15.62 10.28 80.00 75.35%
Latency: 可以理解爲響應時間, 有平均值, 標準偏差, 最大值, 正負一個標準差佔比.
Req/Sec: 每個線程每秒鐘的完成的請求數, 同樣有平均值, 標準偏差, 最大值, 正負一個標準差佔比.
一般我們來說我們主要關注平均值和最大值. 標準差如果太大說明樣本本身離散程度比較高. 有可能系統性能波動很大.
接下來:
5073 requests in 30.09s, 75.28MB read
Socket errors: connect 0, read 5, write 0, timeout 64
Requests/sec: 168.59
Transfer/sec: 2.50MB
30秒鐘總共完成請求數和讀取數據量.
然後是錯誤統計, 上面的統計可以看到, 5個讀錯誤, 64個超時.
然後是所以線程總共平均每秒鐘完成168個請求. 每秒鐘讀取2.5兆數據量.
可以看到, 相對於專業性能測試工具. wrk 的統計信息是非常簡單的. 但是這些信息基本上足夠我們判斷系統是否有問題了.
wrk 默認超時時間是1秒. 這個有點短. 我一般設置爲30秒. 這個看上去合理一點.
如果這樣執行命令:
./wrk -t12 -c100 -d30s -T30s http://www.baidu.com
可以看到超時數就大大降低了, Socket errors 那行沒有了:
Running 30s test @ http://www.baidu.com
threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.16s 1.61s 14.42s 86.52%
Req/Sec 22.59 19.31 108.00 70.98%
requests in 30.10s, 67.25MB read
Requests/sec: 150.61
Transfer/sec: 2.23MB
通過 -d 可以設置測試的持續時間. 一般只要不是太短都是可以的. 看你自己的忍耐程度了.
時間越長樣本越準確. 如果想測試系統的持續抗壓能力, 採用 loadrunner 這樣的專業測試工具會更好一點.
想看看響應時間的分佈情況可以加上--latency參數:
wrk -t12 -c100 -d30s -T30s --latency http://www.baidu.com
Running 30s test @ http://www.baidu.com
threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.22s 1.88s 17.59s 89.70%
Req/Sec 14.47 9.92 98.00 77.06%
Latency Distribution
50% 522.18ms
75% 1.17s
90% 3.22s
99% 8.87s
requests in 30.09s, 57.82MB read
Socket errors: connect 0, read 2, write 0, timeout 0
Requests/sec: 129.19
Transfer/sec: 1.92MB
可以看到50%在0.5秒以內, %75在1.2s 以內. 看上去還不錯.
看到這裏可能有人會說了, HTTP 請求不會總是這麼簡單的, 通常我們會有 POST,GET 等多個 method, 會有 Header, 會有 body 等.
在我第一次知道有 wrk 這個工具的時候他確實還不太完善, 要想測試一些複雜的請求還有點難度. 現在 wrk 支持 lua 腳本. 在這個腳本里你可以修改 method, header, body, 可以對 response 做一下自定義的分析. 因爲是 lua 腳本, 其實這給了你無限的可能. 但是這樣一個強大的功能如果不謹慎使用, 會降低測試端的性能, 測試結果也受到影響.
一般修改method, header, body不會影響測試端性能, 但是操作 request, response 就要格外謹慎了.
我們通過一些測試場景在看看怎麼使用 lua 腳本.
POST + header + body.
首先創建一個 post.lua 的文件:
wrk.method = "POST"
wrk.body = "foo=bar&baz=quux"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"
就這三行就可以了, 當然 headers 可以加入任意多的內容.
然後執行:
wrk -t12 -c100 -d30s -T30s --script=post.lua --latency http://www.baidu.com
當然百度可能不接受這個 post 請求.
對 wrk 對象的修改全局只會執行一次.
通過 wrk 的源代碼可以看到 wrk 對象的源代碼有如下屬性:
local wrk = {
scheme = "http",
host = "localhost",
port = nil,
method = "GET",
path = "/",
headers = {},
body = nil,
thread = nil,
}
schema, host, port, path 這些, 我們一般都是通過 wrk 命令行參數來指定.
wrk 提供的幾個 lua 的 hook 函數:
setup 函數
這個函數在目標 IP 地址已經解析完, 並且所有 thread 已經生成, 但是還沒有開始時被調用. 每個線程執行一次這個函數.
可以通過thread:get(name), thread:set(name, value)設置線程級別的變量.
init 函數
每次請求發送之前被調用.
可以接受 wrk 命令行的額外參數. 通過 -- 指定.
delay函數
這個函數返回一個數值, 在這次請求執行完以後延遲多長時間執行下一個請求. 可以對應 thinking time 的場景.
request函數
通過這個函數可以每次請求之前修改本次請求的屬性. 返回一個字符串. 這個函數要慎用, 會影響測試端性能.
response函數
每次請求返回以後被調用. 可以根據響應內容做特殊處理, 比如遇到特殊響應停止執行測試, 或輸出到控制檯等等.
function response(status, headers, body)
if status ~= 200 then
print(body)
wrk.thread:stop()
end
end
done函數
在所有請求執行完以後調用, 一般用於自定義統計結果.
done = function(summary, latency, requests)
io.write("------------------------------\n")
for _, p in pairs({ 50, 90, 99, 99.999 }) do
n = latency:percentile(p)
io.write(string.format("%g%%,%d\n", p, n))
end
end
下面是 wrk 源代碼中給出的完整例子:
local counter = 1
local threads = {}
function setup(thread)
thread:set("id", counter)
table.insert(threads, thread)
counter = counter + 1
end
function init(args)
requests = 0
responses = 0
local msg = "thread %d created"
print(msg:format(id))
end
function request()
requests = requests + 1
return wrk.request()
end
function response(status, headers, body)
responses = responses + 1
end
function done(summary, latency, requests)
for index, thread in ipairs(threads) do
local id = thread:get("id")
local requests = thread:get("requests")
local responses = thread:get("responses")
local msg = "thread %d made %d requests and got %d responses"
print(msg:format(id, requests, responses))
end
end
測試複合場景時, 也可以通過 lua 實現訪問多個 url.
例如這個複雜的 lua 腳本, 隨機讀取 paths.txt 文件中的 url 列表, 然後訪問.:
counter = 1
math.randomseed(os.time())
math.random(); math.random(); math.random()
function file_exists(file)
local f = io.open(file, "rb")
if f then f:close() end
return f ~= nil
end
function shuffle(paths)
local j, k
local n = #paths
for i = 1, n do
j, k = math.random(n), math.random(n)
paths[j], paths[k] = paths[k], paths[j]
end
return paths
end
function non_empty_lines_from(file)
if not file_exists(file) then return {} end
lines = {}
for line in io.lines(file) do
if not (line == '') then
lines[#lines + 1] = line
end
end
return shuffle(lines)
end
paths = non_empty_lines_from("paths.txt")
if #paths <= 0 then
print("multiplepaths: No paths found. You have to create a file paths.txt with one path per line")
os.exit()
end
print("multiplepaths: Found " .. #paths .. " paths")
request = function()
path = paths[counter]
counter = counter + 1
if counter > #paths then
counter = 1
end
return wrk.format(nil, path)
end
關於 cookie
有些時候我們需要模擬一些通過 cookie 傳遞數據的場景. wrk 並沒有特殊支持, 可以通過 wrk.headers["Cookie"]="xxxxx"實現.
下面是在網上找的一個離職, 取 Response的cookie作爲後續請求的cookie
function getCookie(cookies, name)
local start = string.find(cookies, name .. "=")
if start == nil then
return nil
end
return string.sub(cookies, start + #name + 1, string.find(cookies, ";", start) - 1)
end
response = function(status, headers, body)
local token = getCookie(headers["Set-Cookie"], "token")
if token ~= nil then
wrk.headers["Cookie"] = "token=" .. token
end
end
wrk 本身的定位不是用來替換 loadrunner 這樣的專業性能測試工具的. 其實有這些功能已經完全能應付平時開發過程中的一些性能驗證了.