首页 > 数据库 >redis-benchmark压力测试

redis-benchmark压力测试

时间:2024-07-10 21:43:12浏览次数:8  
标签:20 100.00% benchmark redis alive bytes 100000 测试 requests

01测试-redis-benchmark压力测试

redis自带有redis-benchmark工具做压力测试,经常用来测试新版本,新特性对基准测试性能的影响。参数场景变化下的性能状况。

主要参数:
 -h <hostname>      服务器地址 (default 127.0.0.1)
 -p <port>          端口 (default 6379)
 -s <socket>        socket (overrides host and port)
 -a <password>      密码
 -c <clients>       并行连接数(default 50)
 -n <requests>      总请求数 (default 100000)
 -d <size>          SET/GET请求value大小,单位:bytes (default 3)
 --dbnum <db>       SELECT 指定库 (default 0)
 -k <boolean>       是否采用keep alive模式,0是,1为reconnect (default 1)
 -r <keyspacelen>   为sadd集合操作SET/GET/INCR随机产生key,随机产生value。
 -P <numreq>        pipeline请求数. Default 1 (no pipeline).
 -e                 输出错误信息,每秒显示不超过1个错误。
 -q                 Quiet. 仅仅查看每秒的查询数。
 --csv              输出为CSV格式。
 -l                 循环次数。
 -t <tests>         指定测试命令。
 -I                 打开空连接,并等待。

Examples:

1.进行20个并发请求,10万请求量,测试set、get、incr、lpush,rpush,lpop、rpop、sadd、hset、
spop、range前100个元素、range前300个元素、range前500个元素、range前600个元素、mset。比较全面的测试
   $ redis-benchmark -h 192.168.1.1 -p 6379 -n 100000 -c 20

2.测试set随机数的性能。
   $ redis-benchmark -t set -n 1000000 -r 100000000

3.测试ping,set,get 10万请求性能,csv输出:
   $ redis-benchmark -t ping,set,get -n 100000 --csv

4.测试指定命令性能:
   $ redis-benchmark -r 10000 -n 10000 eval 'return redis.call("ping")' 0

5.测试list随机10000个元素写入lpush:
   $ redis-benchmark -r 10000 -n 10000 lpush mylist __rand_int__


测试记录:
本次测试版本,配置等。

[root@rcsy ~]# redis-cli -a mysql info | grep version
redis_version:4.0.14
gcc_version:4.8.5

内存2G,2颗核心,SSD:30G。

[root@rcsy redis-4.0.14]# redis-benchmark -n 100000 -c 20 -a mysql
====== PING_INLINE ======
  100000 requests completed in 1.99 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.94% <= 1 milliseconds
99.96% <= 2 milliseconds
100.00% <= 3 milliseconds
50251.26 requests per second

====== PING_BULK ======
  100000 requests completed in 2.13 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.92% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
46970.41 requests per second

====== SET ======
  100000 requests completed in 2.02 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.94% <= 1 milliseconds
99.98% <= 2 milliseconds
99.99% <= 3 milliseconds
100.00% <= 3 milliseconds
49431.54 requests per second

====== GET ======
  100000 requests completed in 2.12 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.91% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
47236.65 requests per second

====== INCR ======
  100000 requests completed in 2.09 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.96% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
47801.15 requests per second

====== LPUSH ======
  100000 requests completed in 2.06 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.87% <= 1 milliseconds
99.96% <= 2 milliseconds
99.99% <= 3 milliseconds
100.00% <= 3 milliseconds
48567.27 requests per second

====== RPUSH ======
  100000 requests completed in 2.05 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.93% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
48685.49 requests per second

====== LPOP ======
  100000 requests completed in 2.09 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.95% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
47915.67 requests per second

====== RPOP ======
  100000 requests completed in 2.11 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.93% <= 1 milliseconds
99.98% <= 2 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
47438.33 requests per second

====== SADD ======
  100000 requests completed in 2.14 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.90% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
46620.05 requests per second

====== HSET ======
  100000 requests completed in 2.08 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.91% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 2 milliseconds
47984.64 requests per second

====== SPOP ======
  100000 requests completed in 2.17 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.92% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 3 milliseconds
46146.75 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 2.12 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

99.93% <= 1 milliseconds
99.96% <= 2 milliseconds
99.97% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
47281.32 requests per second

====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 6.34 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

61.85% <= 1 milliseconds
99.77% <= 2 milliseconds
99.98% <= 3 milliseconds
100.00% <= 3 milliseconds
15782.83 requests per second

====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 15.55 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

1.24% <= 1 milliseconds
39.79% <= 2 milliseconds
92.01% <= 3 milliseconds
98.24% <= 4 milliseconds
99.87% <= 5 milliseconds
99.95% <= 6 milliseconds
99.96% <= 7 milliseconds
99.97% <= 8 milliseconds
99.98% <= 9 milliseconds
99.98% <= 10 milliseconds
99.98% <= 11 milliseconds
99.99% <= 12 milliseconds
99.99% <= 15 milliseconds
99.99% <= 16 milliseconds
99.99% <= 24 milliseconds
100.00% <= 25 milliseconds
100.00% <= 26 milliseconds
6431.28 requests per second

====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 22.25 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

0.76% <= 1 milliseconds
15.27% <= 2 milliseconds
50.68% <= 3 milliseconds
83.07% <= 4 milliseconds
93.83% <= 5 milliseconds
97.42% <= 6 milliseconds
99.28% <= 7 milliseconds
99.69% <= 8 milliseconds
99.82% <= 9 milliseconds
99.88% <= 10 milliseconds
99.91% <= 11 milliseconds
99.92% <= 12 milliseconds
99.93% <= 13 milliseconds
99.94% <= 14 milliseconds
99.94% <= 15 milliseconds
99.95% <= 16 milliseconds
99.98% <= 17 milliseconds
99.99% <= 18 milliseconds
99.99% <= 19 milliseconds
99.99% <= 30 milliseconds
99.99% <= 31 milliseconds
100.00% <= 32 milliseconds
100.00% <= 32 milliseconds
4494.38 requests per second

====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 29.40 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

0.04% <= 1 milliseconds
1.65% <= 2 milliseconds
13.74% <= 3 milliseconds
48.50% <= 4 milliseconds
78.79% <= 5 milliseconds
92.05% <= 6 milliseconds
95.91% <= 7 milliseconds
98.48% <= 8 milliseconds
99.74% <= 9 milliseconds
99.86% <= 10 milliseconds
99.89% <= 11 milliseconds
99.90% <= 12 milliseconds
99.91% <= 13 milliseconds
99.92% <= 14 milliseconds
99.93% <= 15 milliseconds
99.94% <= 16 milliseconds
99.96% <= 17 milliseconds
99.97% <= 18 milliseconds
99.98% <= 19 milliseconds
99.98% <= 20 milliseconds
100.00% <= 21 milliseconds
100.00% <= 21 milliseconds
3401.82 requests per second

====== MSET (10 keys) ======
  100000 requests completed in 3.61 seconds
  20 parallel clients
  3 bytes payload
  keep alive: 1

98.40% <= 1 milliseconds
99.93% <= 2 milliseconds
100.00% <= 2 milliseconds
27670.17 requests per second


基本上ping、set、get、lpush、lpop、spop等都达到4-5万多rps,但lrange前100、300、500等就比较慢了,
随着范围越大,月底。从16000--6400---4500--3400,可以看到100-300下降一半多。

压力情况:
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 24657 root      20   0   16908   5788    968 S  99.3  0.3   0:27.31 redis-benchmark
 24624 root      20   0  149408  10744   1288 R  95.4  0.6   2:11.72 redis-server

 可以看到,CPU基本被占满。 按照正常来讲,至少set,get至少上8万。


[root@rcsy ~]# redis-benchmark -t set -n 1000000 -r 100000000
====== SET ======
  1000000 requests completed in 21.45 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.03% <= 1 milliseconds
99.96% <= 2 milliseconds
99.98% <= 3 milliseconds
99.98% <= 4 milliseconds
99.99% <= 5 milliseconds
99.99% <= 8 milliseconds
100.00% <= 9 milliseconds
100.00% <= 10 milliseconds
100.00% <= 12 milliseconds
100.00% <= 12 milliseconds
46620.05 requests per second

[root@rcsy ~]# redis-benchmark -t ping,set,get -n 100000 --csv
"PING_INLINE","48899.75"
"PING_BULK","45351.48"
"SET","44943.82"
"GET","45351.48"

[root@rcsy ~]# redis-benchmark -r 10000 -n 10000 eval 'return redis.call("ping")' 0
====== eval return redis.call("ping") 0 ======
  10000 requests completed in 0.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.29% <= 1 milliseconds
99.51% <= 3 milliseconds
99.74% <= 4 milliseconds
99.96% <= 5 milliseconds
100.00% <= 5 milliseconds
46082.95 requests per second


[root@rcsy ~]# redis-benchmark -r 10000 -n 10000 lpush mylist __rand_int__
====== lpush mylist __rand_int__ ======
  10000 requests completed in 0.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.80% <= 1 milliseconds
99.51% <= 2 milliseconds
99.80% <= 3 milliseconds
100.00% <= 3 milliseconds
46082.95 requests per second

 

标签:20,100.00%,benchmark,redis,alive,bytes,100000,测试,requests
From: https://www.cnblogs.com/rcsy/p/18295072

相关文章

  • java Redission 分布式锁的使用
    在微服务的场景下,一个应用会部署多个实例,在一些业务场景中,需要保证同一时间多个线程只能有一个线程操作资源,分布式锁可以实现这一需求。JAVA中,Redission分布式锁是基于Redis实现的分布式锁,使用简单,只需要关注业务场景和使用到的接口即可。引入依赖<!--https://mvnreposito......
  • 第7章 Vite的测试和调试
    测试和调试是软件开发过程中的重要环节。通过合理的测试策略和调试技巧,可以大幅提高代码的质量和稳定性。本章将介绍如何在Vite项目中进行单元测试、集成测试和端到端测试,以及常用的调试方法和工具。1单元测试单元测试是对最小可测试单元进行验证的测试,通常用于测试......
  • 性能测试的基本概念
    性能测试:不再像功能测试一样单纯的找Bug,而是去找性能指标。转变思维:在做功能测试、自动化测试时,我们基本都是依托界面进行测试,也称GUI测试,我们的目的就是为了跑通功能、程序,并成功找到Bug。但在做性能测试时,我们大部分是headless模式(所谓的:无头,无界面模式),目的不再是单纯......
  • 2024暑假集训测试2
    前言比赛链接。T1、T4比较简单,打完基本就罚坐了,想了三个小时的T2、T3也没想出来。T1酸碱度中和二分答案加贪心即可,先排序,每瓶可装\(a_i\sima_i+2*m\)。点击查看代码#include<bits/stdc++.h>#defineintlonglong#defineendl'\n'#definesortstable_sortus......
  • 渗透测试-信息收集工具
    domainscan调用subfinder被动收集,调用ksubdomain进行dns验证泛解析,CDN判断获取domain相关的web(host:port)资产,使用webscan扫描webscan支持http/httpsscheme自动判断获取statusCode、contentLength、favicon、iconHash、title、wappalyzer、fin"title自动中文解码j......
  • Redis是单线程还是多线程的?
    讲Redis是单线程还是多线程的需要根据redis各版本的一个变化,在Redis的老版本中,redis是单线程的,redis的数据处理读写命令都是由一个线程完成,并且速度很快,是因为redis的数据都是存储在内存中的,避免了磁盘I/O的瓶颈,有通过非阻塞IO和事件驱动模型,使得单线程依旧可以处理大量的数据......
  • Windows的Redis安装及执行文件的路径修改
    一、下载redis的zip文件下载地址:https://github.com/tporadowski/redis/releases这里我们下载Redis-x64-xxx.zip压缩包到C盘,解压至重新命名为redis的文件夹。二、命令配置1.打开redis文件夹,在路径上输入cmd进入命令窗口(也可以打开一个cmd窗口使用cd命令切换目录......
  • Redis基础教程(十八):Redis管道技术
    ......
  • Redis基础教程(十九):Redis分区
    ......
  • Redis安装部署和常用命令
    一、Redis基本概念端口号:63791.关系型数据库和非关系型数据库区别 SQLNoSQL存储结构二维表格结构不固定的,键值对、文档、索引、图形结构、时间序列等扩展方式纵向扩展(提升硬件性能)横向扩展(增加服务器节点数量)事务支持基于ACID原则,事务控制更稳定,细粒度更高......