聊聊Benchmark测试【转载】

根据wiki百科解释: beanchmark问题就是基准测试问题.

1996 International Workshop on Structural Control 会议上提议组建欧洲、亚洲、和美国3个有关SHM的研究小组,并由 Chen倡导建立Benchmark结构,以便进行各种技术的直接比较.

 

许多业内比较出名的工具都提供benchmark 功能

1. Apache Beachmark 简称(ab)

他是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 管道

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是一种基于客户端/服务端模型, Request/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:

$ 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 测试实际上就成了各个厂商展示技术实力的舞台, 任何厂家或者测试者都可以根据组织公布的规范标准, 构建自己最优的系统.

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值