wrk — 小巧輕盈的 http 性能測試工具

　　測試先行是軟件系統質量保證的有效手段. 在單元測試方面, 我們有非常成熟的 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 寫的. 代碼很少. 并且沒有使用很多第三方庫. 所以編譯基本不會遇到什么問題.

　　gitclone https://github.com/wg/wrk.git

　　cdwrk

　　make

　　就 ok了.make 成功以后在目錄下有一個 wrk 文件. 就是它了. 你可以把這個文件復制到其他目錄, 比如 bin 目錄. 或者就這個目錄下執行.

　　如果編譯過程中出現:

　　src/wrk.h:11:25: fatalerror: openssl/ssl.h: Nosuchfileor directory

　　#include

　　是因為系統中沒有安裝openssl的庫.

　　sudo apt-get install libssl-dev

　　或

　　sudo yum install openssl-devel

　　我們先來做一個簡單的性能測試:

　　wrk -t12 -c100 -d30shttp://www.baidu.com

　　30秒鐘結束以后可以看到如下輸出:

　　Running 30s test @ http://www.baidu.com

　　12 threadsand 100 connections

　　ThreadStats Avg Stdev Max +/- Stdev

　　Latency 538.64ms 368.66ms 1.99s 77.33%

　　Req/Sec 15.62 10.28 80.00 75.35%

　　5073 requestsin 30.09s, 75.28MB read

　　Socketerrors: 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 可以用很少的線程模擬大量網路連接的原因. 而現在很多性能工具并沒有采用這種方式, 而是采用提高線程數來實現高并發. 所以并發量一旦設的很高, 測試機自身壓力就很大. 測試效果反而下降.

　　下面是線程統計:

　　ThreadStats 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 requestsin 30.09s, 75.28MB read

　　Socketerrors: connect 0, read 5, write 0, timeout 64

　　Requests/sec: 168.59

　　Transfer/sec: 2.50MB

　　30秒鐘總共完成請求數和讀取數據量.

　　然后是錯誤統計, 上面的統計可以看到, 5個讀錯誤, 64個超時.

原文轉自： https://blog.satikey.com/p/5768/wrk-the-compact-and-lightweight-htt