聊聊benchmark测试
根据wiki百科解释: benchmark问题就是基准测试问题.
1996 International Workshop on Structural Control 会议上提议组建欧洲、亚洲、和美国3个有关SHM的研究小组,并由 Chen倡导建立Benchmark结构,以便进行各种技术的直接比较.
许多业内比较出名的工具都提供benchmark 功能
他是apache 组织下的一款web压力测试工具, 因使用方便简单而著称.
ab一般常用参数是 –n -t 和 -c
-c（concurrency）表示用多少并发来进行测试(模拟并发数);
-t表示并发测试持续时间;
-n表示要发送多少次请求;
注意: 大小写敏感
ab [get] 请求
ab -n 10 -c 3 https://www.baidu.com/
发送10个请求, 模拟3个并发数
Concurrency Level: 3 #当前并发数
Time taken for tests: 0.624 seconds #测试消耗时间
Complete requests: 10 # 完成请求数量
Failed requests: 0 #失败的请求数
Total transferred: 8930 bytes # 共传输数据量
Requests per second: 20.24 [#/sec] (mean) #平均每秒完成请求个数
Time per request: 148.231 [ms] (mean) #每组请求消耗时间
Time per request: 49.410 [ms] (mean, across all concurrent requests) #每个请求消耗时间
Transfer rate: 17.65 [Kbytes/sec] received #传输速率
Percentage of the requests served within a certain time (ms)
50% 104 #104ms内已经完成了50%的请求
80% 161 #161ms内已经完成了80%的请求
ab [post] 请求
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
测试实例:
redis-benchmark -h localhost -p 6379 -c 3 -n 6
3个并发, 6个请求 检测端口号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
测试存取大小为100字节的数据包的性能
$ redis-benchmark -t set,lpush -n 100 -q //测试操作-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是一种基于客户端/服务端模型, reques/Response遵循TCP协议的服务
也就说:
客户端向服务端发送一个查询请求, 监听socket返回, 通常以阻塞模式, 等待服务端响应. 服务端处理命令, 并将结果返回给客户端.
Redis很早就支持管道（pipelining）技术，因此无论你运行的是什么版本，你都可以使用管道（pipelining）操作Redis。
下面是一个使用的例子：
$ (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测试中最重要的是标准规范，也就是说他是一个评价方式，工具等因素已经不重要，只要大家都用同一标准规范、同一工具进行系统测试，那么测试结果也就具有了比较意义。Benchmark 测试实际上就成了各个厂商展示技术实力的舞台, 任何厂家或者测试者都可以根据组织公布的规范标准, 构建自己最优的系统.
参考文献:
https://redis.io/topics/pipelining
https://en.wikipedia.org/wiki/HTTP_pipelining
今日精选推荐
JMeter接口测试-if控制器
JMeter数据库操作
Jmeter接口测试-正则表达式
JMeter中文返回乱码
Jmeter接口测试-参数化
JMeter接口测试-基础
测试-感想
咨询工作加微信
扫描二维码
欢迎自荐和推荐, 需要的微信推送简历!
请猛戳下面二维码了解更多
总结
以上是生活随笔为你收集整理的聊聊benchmark测试的全部内容，希望文章能够帮你解决所遇到的问题。
- 上一篇： go Jenkins流水线极速打包镜像上
- 下一篇： WriteError Resulting