聊聊benchmark测试
根據(jù)wiki百科解釋: benchmark問(wèn)題就是基準(zhǔn)測(cè)試問(wèn)題.
1996 International Workshop on Structural Control 會(huì)議上提議組建歐洲、亞洲、和美國(guó)3個(gè)有關(guān)SHM的研究小組,并由 Chen倡導(dǎo)建立Benchmark結(jié)構(gòu),以便進(jìn)行各種技術(shù)的直接比較.
?
許多業(yè)內(nèi)比較出名的工具都提供benchmark 功能
他是apache 組織下的一款web壓力測(cè)試工具, 因使用方便簡(jiǎn)單而著稱.
ab一般常用參數(shù)是 –n? ?-t 和 -c
-c（concurrency）表示用多少并發(fā)來(lái)進(jìn)行測(cè)試(模擬并發(fā)數(shù));
-t表示并發(fā)測(cè)試持續(xù)時(shí)間;
-n表示要發(fā)送多少次請(qǐng)求;
注意: 大小寫(xiě)敏感
?
?
ab [get] 請(qǐng)求
ab -n 10 -c 3 https://www.baidu.com/
發(fā)送10個(gè)請(qǐng)求, 模擬3個(gè)并發(fā)數(shù)
Concurrency Level:????? 3?? #當(dāng)前并發(fā)數(shù)
Time taken for tests:?? 0.624 seconds?? #測(cè)試消耗時(shí)間
Complete requests:????? 10? # 完成請(qǐng)求數(shù)量
Failed requests:??????? 0?? #失敗的請(qǐng)求數(shù)
Total transferred:????? 8930 bytes # 共傳輸數(shù)據(jù)量
Requests per second:??? 20.24 [#/sec] (mean)? #平均每秒完成請(qǐng)求個(gè)數(shù)
Time per request:?????? 148.231 [ms] (mean) #每組請(qǐng)求消耗時(shí)間
Time per request:?????? 49.410 [ms] (mean, across all concurrent requests) #每個(gè)請(qǐng)求消耗時(shí)間
Transfer rate:????????? 17.65 [Kbytes/sec] received #傳輸速率
Percentage of the requests served within a certain time (ms)
? 50%??? 104?? #104ms內(nèi)已經(jīng)完成了50%的請(qǐng)求
? 80%??? 161?? #161ms內(nèi)已經(jīng)完成了80%的請(qǐng)求
?
?
ab [post] 請(qǐng)求
ab -n 100? -c 10 -p 'postdata.txt' -T 'application/x-www-form-urlencoded' 'http://xxx.api.com/'
-p postfile
-T Content-type header to use for POST/PUT data,
'application/x-www-form-urlencoded' Default is 'text/plain'
?
2 Redis-Beachmark
?
?
測(cè)試實(shí)例:
redis-benchmark -h localhost -p 6379 -c 3 -n 6
3個(gè)并發(fā), 6個(gè)請(qǐng)求 檢測(cè)端口號(hào)6379的redis 性能
$ redis-benchmark -h localhost -p 6379 -c 3 -n 6
====== PING_INLINE ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
6000.00 requests per second
?
====== PING_BULK ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== SET ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
6000.00 requests per second
?
====== GET ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== INCR ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== LPUSH ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
6000.00 requests per second
?
====== RPUSH ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== LPOP ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== RPOP ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
6000.00 requests per second
?
====== SADD ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== HSET ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== SPOP ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== LPUSH (needed to benchmark LRANGE) ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
====== LRANGE_100 (first 100 elements) ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
66.67% <= 1 milliseconds
100.00% <= 1 milliseconds
3000.00 requests per second
?
====== LRANGE_300 (first 300 elements) ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
3000.00 requests per second
?
====== LRANGE_500 (first 450 elements) ======
? 6 requests completed in 0.01 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
50.00% <= 1 milliseconds
100.00% <= 1 milliseconds
1000.00 requests per second
?
====== LRANGE_600 (first 600 elements) ======
? 6 requests completed in 0.01 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
66.67% <= 1 milliseconds
100.00% <= 1 milliseconds
1000.00 requests per second
?
====== MSET (10 keys) ======
? 6 requests completed in 0.00 seconds
? 3 parallel clients
? 3 bytes payload
? keep alive: 1
?
100.00% <= 0 milliseconds
inf requests per second
?
?
redis-benchmark -h localhost -p 6379 -q -d 100
測(cè)試存取大小為100字節(jié)的數(shù)據(jù)包的性能
?
?
$ redis-benchmark -t set,lpush -n 100 -q //測(cè)試操作-t(set, lpush)的性能
SET: 20000.00 requests per second
LPUSH: 6666.67 requests per second
?
$ redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q?? //redis 管道Pipelining
SET: 142857.14 requests per second
GET: 117647.05 requests per second
LPUSH: 181818.19 requests per second
LPOP: 200000.00 requests per second
?
Redis是一種基于客戶端/服務(wù)端模型, reques/Response遵循TCP協(xié)議的服務(wù)
也就說(shuō):
客戶端向服務(wù)端發(fā)送一個(gè)查詢請(qǐng)求, 監(jiān)聽(tīng)socket返回, 通常以阻塞模式, 等待服務(wù)端響應(yīng). 服務(wù)端處理命令, 并將結(jié)果返回給客戶端.
?
Redis很早就支持管道（pipelining）技術(shù)，因此無(wú)論你運(yùn)行的是什么版本，你都可以使用管道（pipelining）操作Redis。
下面是一個(gè)使用的例子：
?
$ (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
+PONG
+PONG
+PONG
?
?
$ (echo -en "PING\r\n SET key redis\r\nGET key\r\nINCR x\r\nINCR x\r\nINCR x\r\n"; sleep 10) | nc localhost 6379
?
Using the TCP loopback:
?
louie-mac:~ louiezhou$ redis-benchmark -q -n 100000 -d 256
PING_INLINE: 36023.05 requests per second
PING_BULK: 36697.25 requests per second
SET: 34710.17 requests per second
GET: 35919.54 requests per second
INCR: 36927.62 requests per second
LPUSH: 27151.78 requests per second
RPUSH: 37160.91 requests per second
LPOP: 25348.54 requests per second
RPOP: 29958.06 requests per second
SADD: 34176.35 requests per second
HSET: 33411.29 requests per second
SPOP: 34002.04 requests per second
LPUSH (needed to benchmark LRANGE): 37105.75 requests per second
LRANGE_100 (first 100 elements): 10824.85 requests per second
LRANGE_300 (first 300 elements): 3895.90 requests per second
LRANGE_500 (first 450 elements): 2820.95 requests per second
LRANGE_600 (first 600 elements): 2107.26 requests per second
MSET (10 keys): 27987.69 requests per second
?
Benchmark測(cè)試中最重要的是標(biāo)準(zhǔn)規(guī)范，也就是說(shuō)他是一個(gè)評(píng)價(jià)方式，工具等因素已經(jīng)不重要，只要大家都用同一標(biāo)準(zhǔn)規(guī)范、同一工具進(jìn)行系統(tǒng)測(cè)試，那么測(cè)試結(jié)果也就具有了比較意義。Benchmark 測(cè)試實(shí)際上就成了各個(gè)廠商展示技術(shù)實(shí)力的舞臺(tái), 任何廠家或者測(cè)試者都可以根據(jù)組織公布的規(guī)范標(biāo)準(zhǔn), 構(gòu)建自己最優(yōu)的系統(tǒng).
?
?
參考文獻(xiàn):
https://redis.io/topics/pipelining
https://en.wikipedia.org/wiki/HTTP_pipelining
今日精選推薦
JMeter接口測(cè)試-if控制器
JMeter數(shù)據(jù)庫(kù)操作
Jmeter接口測(cè)試-正則表達(dá)式
JMeter中文返回亂碼
Jmeter接口測(cè)試-參數(shù)化
JMeter接口測(cè)試-基礎(chǔ)
測(cè)試-感想
?
?
咨詢工作加微信
掃描二維碼
?
歡迎自薦和推薦, 需要的微信推送簡(jiǎn)歷!
請(qǐng)猛戳下面二維碼了解更多
?
總結(jié)
以上是生活随笔為你收集整理的聊聊benchmark测试的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： go Jenkins流水线极速打包镜像上
- 下一篇： WriteError Resulting