不會用ab和wrk做接口壓測？來，帶你實踐

| 導語 日常運營做活動會帶來很大的請求量，爲了評估當前系統是否能支撐住預估的請求量，那麼就對訪問量大的接口做壓測，一般會進行多輪壓測，主要是排查系統隱藏的bug和發現可以優化的點，然後根據壓測結果評估當前系統負載，然後準備擴容等工作，使系統能穩定可靠的支撐運營活動。

壓測術語說明

1. 吞吐率

概念：服務器併發處理能力的量化描述，單位是reqs/s，指的是某個併發用戶數下單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數，稱之爲最大吞吐率。 計算公式：總請求數 / 處理完成這些請求數所花費的時間，即 Request per second = Complete requests / Time taken for tests

2. 併發連接數

概念：某個時刻服務器所接受的請求數目

3. 併發用戶數

概念：要注意區分這個概念和併發連接數之間的區別，一個用戶可能同時會產生多個會話，也即連接數。

4.用戶平均請求等待時間

計算公式：處理完成所有請求數所花費的時間/ （總請求數 / 併發用戶數），即 Time per request = Time taken for tests /（ Complete requests / Concurrency Level）

以上是我們壓測關心的一些指標，其中吞吐率是我們最關心的指標。

1. 壓測工具ab實踐

ab用法介紹

這裏介紹常用的參數和用法

-n requests 總請求數
-c concurrency 一次產生的請求數，可以理解爲併發數
-t timelimit 測試所進行的最大秒數, 可以當做請求的超時時間
-p postfile 包含了需要POST的數據的文件
-T content-type POST數據所使用的Content-type頭信息

get請求：ab -n 1000 -c 10 -t 10 "testurl.com/get_user?ui…"

post請求：ab -n 1000 -c 10 -t 10 -p post.json -T "application/x-www-form-urlencoded" "testurl.com/add_user" 其中post.json是你的那個接口需要的json參數

{"name":"bob","age":12,"sex":1}

編寫腳本批量壓測接口(多個同時同時壓測)

在實際壓測中，我們往往要壓測很多接口，而很多接口都有同時請求的情況，所以我們不能單獨一個一個測接口得到TPS，所以需要自己編寫腳本，去完成同時壓測的要求。以下是寫的一個簡單的批量壓測腳本test.sh：

#!/bin/sh

RESULT_DIR="/data/home/yawenxu/TestResult/"
jsonFileArr="ff0e_00.json ff0e_02.json ff0e_05.json ff0e_06.json ff0e_07.json ff0e_08.json ff0e_10.json ff0e_11.json" # 每個接口post需要的json參數的文件
concurrency=${1-1} #併發數
count=${2-1}  #總請求數
input_file_name=$3
exec_single_ab(){
        if [ -f $1 ];then
                /usr/bin/ab -n $2 -c $3 -p $1 -T "application/x-www-form-urlencoded" "http://$4" >$RESULT_DIR$1$2"_nginx.txt" 2>&1 &
        else
                echo $1" is not exists"
        fi

}
exec_loop_ab(){
        for item_name in $jsonFileArr
        do
                exec_single_ab $item_name $concurrency $count "http://api.com/xxx" &
        done
}

if [ -f $input_file_name ];then
        exec_single_ab $input_file_name $concurrency $count &
else
        exec_loop_ab &
fi

這個腳本保證了多個接口同時壓測，同時將每個接口的壓測報告保存到文件裏，便於分析。執行命令sh test.sh 10000 10000 一次性生成壓測報告文件如下：

ff0e_00.json10000_nginx.txt  ff0e_05.json10000_nginx.txt  ff0e_07.json10000_nginx.txt  ff0e_10.json10000_nginx.txt
ff0e_02.json10000_nginx.txt  ff0e_06.json10000_nginx.txt  ff0e_08.json10000_nginx.txt  ff0e_11.json10000_nginx.txt

某個文件的壓測報告如下圖

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.voovlive.com (be patienComCompleted 100 requesComCompleted 200 requesComCompleted 300 requesComCompleted 400 requesCompleted 500 requests
Finished 500 requests


Server Software:        
Server Hostname:        10.228.15.46
Server Port:            3002

Document Path:          /test/get
Document Length:        248 bytes

Concurrency Level:      500
Time taken for tests:   2.523 seconds
Complete requests:      500
Failed requests:        0
Write errors:           0
Total transferred:      161500 bytes
Total POSTed:           359640
HTML transferred:       124000 bytes
Requests per second:    198.19 [#/sec] (mean)
Time per request:       2522.808 [ms] (mean)
Time per request:       5.046 [ms] (mean, across all concurrent requests)
Transfer rate:          62.52 [Kbytes/sec] received
                        139.21 kb/s sent
                        201.73 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   13   4.1     14      17
Processing:   416  948 516.2    828    2485
Waiting:      415  947 516.4    827    2485
Total:        432  961 513.2    841    2497

Percentage of the requests served within a certain time (ms)
  50%    841
  66%    913
  75%    990
  80%   1213
  90%   2039
  95%   2064
  98%   2476
  99%   2484
 100%   2497 (longest request)
uest)

我們比較關心的幾個點 1.Concurrency Level: 500 // 併發數 2.Time taken for tests: 2.523 seconds // 總花費時間 3.Complete requests: 500 // 完成請求數 4.Failed requests: 0 // 失敗請求數 5.Requests per second: 198.19 [#/sec] (mean) // 吞吐率（TPS） 6.Time per request: 2522.808 [ms] (mean) // 一個請求花費的平均時間 7.Percentage of the requests served within a certain time (ms) // 請求的時間分佈情況 壓測主要是評估當前系統的負載，所以一般看看吞吐率(TPS)和成功率就夠了，如果想評估接口性能，可以查看第6和第7項數據。往往需要改變壓測參數(併發數和總請求數)多壓測幾次，纔會得到準確的TPS。

問題總結

ab優點如下：

1. 簡單易用
2. 支持post請求，接受json文件作爲參數 （方便編寫腳本批量測試）
3. 壓測量不大的情況下夠用(1024個併發以下)

但是也有一些明顯缺點

1. 無法持續時間壓測，控制速度壓測。ab沒有這個功能。

2. 壓測量起不來。主要是ab只能利用單個cpu，只能是單進程，而系統限制每個進程打開的最大文件數爲1024，所以最多1024個線程，如果是多核cpu，就浪費了這些資源。

3. 如果中途的請求被服務器拒絕了，測試報告不完整，無法得出已完成請求的壓測情況。以下是中途被服務器拒絕的報告，很不友好:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 100.125.176.120 (be patienCompleted 100 requests
Completed 200 requests
ComCompleted 300 requesComCompleted 400 requesComCompleted 500 requesapr_socket_recv: Connection timed out (110)
Total of 536 requests completed
ed

2.壓測工具wrk實踐

發現ab的這些缺點，無法滿足目前的壓測要求之後，去查看了很多壓測工具，最後發現了wrk這個同樣易用，沒有上面ab的缺點，使用學習成本稍高一點的壓測工具。 wrk負載測試時可以運行在一個或者多核CPU，wrk結合了可伸縮的事件通知系統epoll和kqueue等多線程設計思想。

wrk用法介紹

1. 安裝

壓測是在測試環境的機器上進行的，由於測試環境機器訪問不了外網所以安裝一些工具較爲麻煩。爲什麼要到測試環境機器上進行呢？因爲

1. 本機windows環境，安裝同樣比較麻煩
2. 壓測現網服務有些是通過ip壓測的，本機無法訪問。
3. 測試環境機器性能比較高，併發請求量更大一些。

安裝步驟如下

1. 下載安裝包到本地源碼地址
2. 本地上傳壓縮包到測試環境機器
3. 在測試環境解壓，編譯，如果編譯報錯，少了一些依賴庫，按照同樣的步驟安裝。

2. 主要參數說明

-t --threads   開啓的線程數，用於控制併發請求速度。最大值一般是cpu總核心數的2-4倍
-c --conections 保持的連接數（會話數）
-d --duration 壓測持續時間(s)
-s --script 加載lua腳本（post請求寫一些參數到腳本里）
-H --header 在請求頭部添加一些參數
--latency 壓測報告輸出請求回包花費時間分佈
--timeout 請求的最大超時時間(s),這個很有用

簡單的例子 wrk -t4 -c1000 -d30s -T30s --latency www.baidu.com 上面這條命令的意思是用4個線程來模擬1000個併發連接，整個測試持續30秒，連接超時30秒，打印出請求的延遲統計信息。

編寫腳本批量壓測接口(多個接口同時壓測)

1.編寫lua腳本 因爲接口需要json格式參數，所以首先編寫lua腳本，在lua腳本里添加json參數, ff0e_05.lua如下

request = function()
    local headers = { }
    headers['Content-Type'] = "application/json"
    body = '{"uin":"123","lang":"en"}'
    return wrk.format('POST', nil, headers, body)
end

1. 編寫壓測腳本 一個簡單的批量壓測腳本test.sh：

#!/bin/sh

RESULT_DIR="/data/home/yawenxu/wrkTestResult/"
luaFileArr="ff0e_00.lua ff0e_02.lua ff0e_05.lua ff0e_06.lua ff0e_07.lua ff0e_08.lua ff0e_10.lua ff0e_11.lua" # 每個接口post需要的json參數的lua文件
concurrency=${1-1} #開啓線程數，用於控制速度
count=${2-1}  #保持連接數
continueTime=${3-1}  # 持續時間
input_file_name=$4
exec_single_wrk(){
        if [ -f $1 ];then
                ./wrk -t $2 -c $3 -d $continueTime --script=$1 --latency --timeout 10 "http://$4" >$RESULT_DIR$1$3"_nginx.txt" 2>&1 &
        else
                echo $1" is not exists"
        fi
}

exec_loop_wrk(){
        for item_name in $luaFileArr
        do
                exec_single_wrk $item_name $concurrency $count "http://api.com/xxx" &
        done
}

if [ -f $input_file_name ];then
        exec_single_wrk $input_file_name $concurrency $count &
else
        exec_loop_wrk &
fi

這個腳本保證了多個接口同時壓測，同時將每個接口的壓測報告保存到文件裏，便於分析。執行命令sh test.sh 12 5000 10 會一次性生成所有接口的壓測報告文件，其中一份壓測報告如下:

Running 10s test @ http://api.com/xxx
  12 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.27s   386.53ms   1.99s    59.87%
    Req/Sec    53.85     75.74   777.00     93.91%
  Latency Distribution
     50%    1.26s
     75%    1.61s
     90%    1.80s
     99%    1.97s
  3641 requests in 10.10s, 1.88MB read
  Socket errors: connect 0, read 0, write 0, timeout 2146
Requests/sec:    360.51
Transfer/sec:    190.82KB

看上面的報告，可以看出保持連接數5000，持續壓測10s，超時時間10s，這種情況接口超時情況特別嚴重，總請求數3641超時數目2146，但是查看 Latency Distribution又發現99%的請求都在1.97s內回包，這個時候就要考慮nginx接入層的轉發能力是不是比較低導致的。所以我們可以壓測下我們服務的具體ip，不通過nginx接入層。最後壓測發現的確是nginx流量轉發有評價瓶頸，那我們可以採取擴容nginx的措施。

在做腳本壓測的同時，需要實時查看現網服務的cpu使用率和系統負載情況，發現cpu使用率和負載明顯飆升。命令:top -d 1，可以參考使用 Perf 和火焰圖分析 CPU 性能

問題總結

1. 壓測不能做單獨接口的壓測，必須模擬實際情況，對實際有同時請求的很多接口同時壓測，這樣才能發現系統的問題
2. 壓測需要考慮多方面因素。

1. 壓測所用機器的性能，每秒發出的請求數能不能達到預估值
2. 壓測工具每秒發出的請求數能不能達到預估值，以及能不能持續壓測。
3. 壓測現網服務，需要考慮到依賴的其他服務，比如接入層(nginx)自身的處理能力，可以對接入層做壓測。
4. 壓測的時候需要實時查看現網服務的cpu使用率和系統負載情況，這個可以發現編碼上的bug。