博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
redis-benchmark压力测试使用
阅读量:4045 次
发布时间:2019-05-24

本文共 6869 字,大约阅读时间需要 22 分钟。

redis-benchmark是redis官方提供的压测工具,安装好redis后,默认安装。使用简便。语法:Usage: redis-benchmark [-h 
] [-p
] [-c
] [-n
[-k
]模拟20个客户端,100000次请求redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20模拟1000000次请求,生成100000000个set结构redis-benchmark -t set -n 1000000 -r 100000000模拟ping,set,get 各100000次,结果输出到csv文件redis-benchmark -t ping,set,get -n 100000 --csv模拟100000次键foo的存储性能redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"模拟一下十万次请求:redis-benchmark -n 100000 -q模拟一下百万级访问近百万key:[root@vm-ArthurGuo-1 ~]# redis-benchmark -n 1000000 -r1000000 -q模拟一个万级用户的并发: redis-benchmark -c 10000 -n 1000000 -r 1000000 -qredis-benchmark --helpUsage: redis-benchmark [-h
] [-p
] [-c
] [-n
[-k
] -h
     Server hostname (default 127.0.0.1)  --主机ip地址 -p
         Server port (default 6379) --端口 -s
       Server socket (overrides host and port) --socket(如果测试在服务器上测可以用socket方式) -c
      Number of parallel connections (default 50) --客户端连接数 -n
     Total number of requests (default 10000) --总请求数 -d
         Data size of SET/GET value in bytes (default 2) --set、get的value大小 -dbnum
       SELECT the specified db number (default 0) --选择哪个数据库测试(一般0-15) -k
      1=keep alive 0=reconnect (default 1) --是否采用keep alive模式 -r
  Use random keys for SET/GET/INCR, random values for SADD --随机产生键值时的随机数范围  Using this option the benchmark will expand the string __rand_int__  inside an argument with a 12 digits number in the specified range  from 0 to keyspacelen-1. The substitution changes every time a command  is executed. Default tests use this to hit random keys in the  specified range. -P
       Pipeline
requests. Default 1 (no pipeline). --pipeline的个数(如果使用pipeline会把多个命令封装在一起提高效率) -q                 Quiet. Just show query/sec values --仅仅查看每秒的查询数 --csv              Output in CSV format --用csv方式输出 -l                 Loop. Run the tests forever --循环次数 -t
        Only run the comma separated list of tests. The test --指定命令                    names are the same as the ones produced as output. -I                 Idle mode. Just open N idle connections and wait. --仅打开n个空闲链接Examples: Run the benchmark with the default configuration against 127.0.0.1:6379:   $ redis-benchmark Use 20 parallel clients, for a total of 100k requests, against 192.168.1.1:   $ redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20  --测试set、get、mset、sadd等场景下的性能 Fill 127.0.0.1:6379 with about 1 million keys only using the SET test:   $ redis-benchmark -t set -n 1000000 -r 100000000  --测试set随机数的性能 Benchmark 127.0.0.1:6379 for a few commands producing CSV output:   $ redis-benchmark -t ping,set,get -n 100000 --csv  --使用csv的输出方式测试 Benchmark a specific command line:   $ redis-benchmark -r 10000 -n 10000 eval 'return redis.call("ping")' 0 --测试基本命令的速度 Fill a list with 10000 random elements:   $ redis-benchmark -r 10000 -n 10000 lpush mylist __rand_int__  --测试list入队的速度 On user specified command lines __rand_int__ is replaced with a random integer with a range of values selected by the -r option.下面我就测下我的笔记本电脑的redis性能:[root@db1 ~]# redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 20====== PING_INLINE ======  100000 requests completed in 1.09 seconds  20 parallel clients  3 bytes payload  keep alive: 199.86% <= 1 milliseconds100.00% <= 2 milliseconds100.00% <= 2 milliseconds91659.03 requests per second====== PING_BULK ======  100000 requests completed in 1.07 seconds  20 parallel clients  3 bytes payload  keep alive: 199.94% <= 1 milliseconds100.00% <= 1 milliseconds93545.37 requests per second====== SET ======  100000 requests completed in 1.03 seconds  20 parallel clients  3 bytes payload  keep alive: 199.78% <= 1 milliseconds100.00% <= 1 milliseconds97087.38 requests per second====== GET ======  100000 requests completed in 1.10 seconds  20 parallel clients  3 bytes payload  keep alive: 199.81% <= 1 milliseconds100.00% <= 1 milliseconds90909.09 requests per second====== INCR ======  100000 requests completed in 1.09 seconds  20 parallel clients  3 bytes payload  keep alive: 199.86% <= 1 milliseconds100.00% <= 1 milliseconds91911.76 requests per second====== LPUSH ======  100000 requests completed in 1.07 seconds  20 parallel clients  3 bytes payload  keep alive: 199.85% <= 1 milliseconds100.00% <= 1 milliseconds93808.63 requests per second====== LPOP ======  100000 requests completed in 1.01 seconds  20 parallel clients  3 bytes payload  keep alive: 199.89% <= 1 milliseconds100.00% <= 1 milliseconds98522.17 requests per second====== SADD ======  100000 requests completed in 1.04 seconds  20 parallel clients  3 bytes payload  keep alive: 199.76% <= 1 milliseconds100.00% <= 1 milliseconds96153.85 requests per second====== SPOP ======  100000 requests completed in 1.11 seconds  20 parallel clients  3 bytes payload  keep alive: 199.92% <= 1 milliseconds100.00% <= 1 milliseconds90171.33 requests per second====== LPUSH (needed to benchmark LRANGE) ======  100000 requests completed in 1.09 seconds  20 parallel clients  3 bytes payload  keep alive: 199.82% <= 1 milliseconds100.00% <= 1 milliseconds92081.03 requests per second====== LRANGE_100 (first 100 elements) ======  100000 requests completed in 2.53 seconds  20 parallel clients  3 bytes payload  keep alive: 199.91% <= 1 milliseconds100.00% <= 2 milliseconds100.00% <= 2 milliseconds39603.96 requests per second====== LRANGE_300 (first 300 elements) ======  100000 requests completed in 5.17 seconds  20 parallel clients  3 bytes payload  keep alive: 191.01% <= 1 milliseconds99.94% <= 2 milliseconds100.00% <= 2 milliseconds19346.10 requests per second====== LRANGE_500 (first 450 elements) ======  100000 requests completed in 7.41 seconds  20 parallel clients  3 bytes payload  keep alive: 161.54% <= 1 milliseconds98.36% <= 2 milliseconds99.96% <= 3 milliseconds100.00% <= 4 milliseconds100.00% <= 4 milliseconds13498.92 requests per second====== LRANGE_600 (first 600 elements) ======  100000 requests completed in 9.49 seconds  20 parallel clients  3 bytes payload  keep alive: 141.24% <= 1 milliseconds91.89% <= 2 milliseconds99.78% <= 3 milliseconds100.00% <= 4 milliseconds100.00% <= 4 milliseconds10541.85 requests per second====== MSET (10 keys) ======  100000 requests completed in 1.68 seconds  20 parallel clients  3 bytes payload  keep alive: 199.28% <= 1 milliseconds100.00% <= 1 milliseconds59382.42 requests per second从以上可以看出,20个客户端,每种场景均有100000次请求:ping、set、get、lpush、lpop、spop等都达到90000多rps,但lrange前100、300、500等就比较慢了,才10000多rps。再测下set的速度:[root@db1 ~]# redis-benchmark -t set -n 1000000 -r 100000000====== SET ======  1000000 requests completed in 10.56 seconds  50 parallel clients  3 bytes payload  keep alive: 198.65% <= 1 milliseconds99.90% <= 2 milliseconds99.99% <= 3 milliseconds100.00% <= 3 milliseconds94741.83 requests per second每秒94741次,非常快再来测试下list的入队速度:[root@db1 ~]# redis-benchmark -r 100000 -n 100000 lpush mylist __rand_int__====== lpush mylist __rand_int__ ======  100000 requests completed in 0.97 seconds  50 parallel clients  3 bytes payload  keep alive: 198.83% <= 1 milliseconds100.00% <= 1 milliseconds102774.92 requests per second超过了10w次。———————————————

 

转载地址:http://cxwci.baihongyu.com/

你可能感兴趣的文章
【leetcode】Linked List Cycle (python)
查看>>
【leetcode】Linked List Cycle (python)
查看>>
【leetcode】Candy(python)
查看>>
【leetcode】Clone Graph(python)
查看>>
【leetcode】Sum Root to leaf Numbers
查看>>
【leetcode】Pascal's Triangle II (python)
查看>>
java自定义容器排序的两种方法
查看>>
如何成为编程高手
查看>>
本科生的编程水平到底有多高
查看>>
AngularJS2中最基本的文件说明
查看>>
从头开始学习jsp(2)——jsp的基本语法
查看>>
使用与或运算完成两个整数的相加
查看>>
备忘:java中的递归
查看>>
DIV/CSS:一个贴在左上角的标签
查看>>
Solr及Spring-Data-Solr入门学习
查看>>
Vue组件
查看>>
python_time模块
查看>>
python_configparser(解析ini)
查看>>
selenium学习资料
查看>>
<转>文档视图指针互获
查看>>