redis-benchmark测试Redis集群性能

最新推荐文章于 2025-09-24 14:05:22 发布
原创 最新推荐文章于 2025-09-24 14:05:22 发布 · 2.5k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #jedis #缓存 #云服务 #软件测试

本文详细测试了Redis5三主三从cluster在100并发连接下，处理100000个请求，包括ping、set、get等操作的性能，以及对100字节和3000字节数据包的响应，并特别关注了大容量数据的set和get操作。此外，还测试了对特定值的脚本执行性能。

基础环境配置：Redis5 三主三从cluster

1、100个并发连接，100000个请求，检测host为172.16.254.124端口为7004的redis服务器性能

redis-benchmark -h 172.16.254.124 -p 7004 -c 100 -n 100000

====== PING_INLINE ======
  100000 requests completed in 1.71 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
72.54% <= 1 milliseconds
98.24% <= 2 milliseconds
99.80% <= 3 milliseconds
99.92% <= 6 milliseconds
99.96% <= 7 milliseconds
100.00% <= 7 milliseconds
58513.75 requests per second
====== PING_BULK ======
  100000 requests completed in 1.71 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
78.17% <= 1 milliseconds
96.93% <= 2 milliseconds
99.53% <= 3 milliseconds
99.74% <= 4 milliseconds
99.81% <= 5 milliseconds
99.90% <= 6 milliseconds
99.96% <= 10 milliseconds
99.96% <= 11 milliseconds
100.00% <= 11 milliseconds
58411.21 requests per second
====== SET ======
  100000 requests completed in 1.65 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
84.03% <= 1 milliseconds
98.08% <= 2 milliseconds
99.77% <= 3 milliseconds
99.80% <= 5 milliseconds
99.82% <= 6 milliseconds
99.95% <= 7 milliseconds
100.00% <= 7 milliseconds
60679.61 requests per second
====== GET ======
  100000 requests completed in 1.62 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
86.78% <= 1 milliseconds
98.19% <= 2 milliseconds
99.63% <= 3 milliseconds
99.93% <= 4 milliseconds
99.95% <= 5 milliseconds
99.95% <= 6 milliseconds
100.00% <= 6 milliseconds
61766.52 requests per second
====== INCR ======
  100000 requests completed in 1.64 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
82.68% <= 1 milliseconds
97.82% <= 2 milliseconds
99.69% <= 3 milliseconds
99.87% <= 4 milliseconds
99.90% <= 6 milliseconds
99.96% <= 7 milliseconds
100.00% <= 7 milliseconds
61087.36 requests per second
====== LPUSH ======
  100000 requests completed in 2.08 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
13.72% <= 1 milliseconds
92.05% <= 2 milliseconds
99.23% <= 3 milliseconds
99.76% <= 4 milliseconds
99.80% <= 5 milliseconds
99.88% <= 6 milliseconds
99.90% <= 8 milliseconds
99.90% <= 15 milliseconds
99.91% <= 21 milliseconds
99.91% <= 22 milliseconds
99.97% <= 23 milliseconds
100.00% <= 23 milliseconds
48100.05 requests per second
====== RPUSH ======
  100000 requests completed in 1.74 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
29.96% <= 1 milliseconds
94.94% <= 2 milliseconds
99.32% <= 3 milliseconds
99.97% <= 4 milliseconds
100.00% <= 4 milliseconds
57570.52 requests per second
====== LPOP ======
  100000 requests completed in 1.82 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
25.36% <= 1 milliseconds
92.14% <= 2 milliseconds
99.16% <= 3 milliseconds
99.90% <= 4 milliseconds
99.90% <= 5 milliseconds
99.92% <= 6 milliseconds
99.95% <= 7 milliseconds
99.98% <= 8 milliseconds
100.00% <= 8 milliseconds
54824.56 requests per second
====== RPOP ======
  100000 requests completed in 1.81 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
31.58% <= 1 milliseconds
94.07% <= 2 milliseconds
98.94% <= 3 milliseconds
99.90% <= 4 milliseconds
100.00% <= 5 milliseconds
55218.11 requests per second
====== SADD ======
  100000 requests completed in 1.62 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
85.65% <= 1 milliseconds
98.11% <= 2 milliseconds
99.73% <= 3 milliseconds
99.92% <= 4 milliseconds
100.00% <= 5 milliseconds
61576.36 requests per second
====== HSET ======
  100000 requests completed in 1.57 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
88.79% <= 1 milliseconds
98.84% <= 2 milliseconds
99.79% <= 3 milliseconds
99.85% <= 4 milliseconds
99.89% <= 5 milliseconds
99.90% <= 8 milliseconds
99.95% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 10 milliseconds
63532.40 requests per second
====== SPOP ======
  100000 requests completed in 1.73 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
73.73% <= 1 milliseconds
97.28% <= 2 milliseconds
99.78% <= 3 milliseconds
99.90% <= 5 milliseconds
99.94% <= 6 milliseconds
99.98% <= 7 milliseconds
100.00% <= 7 milliseconds
57670.13 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 1.68 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
30.56% <= 1 milliseconds
92.52% <= 2 milliseconds
99.34% <= 3 milliseconds
99.97% <= 4 milliseconds
100.00% <= 4 milliseconds
59594.76 requests per second
====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 2.99 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
0.34% <= 1 milliseconds
81.88% <= 2 milliseconds
95.99% <= 3 milliseconds
98.89% <= 4 milliseconds
99.71% <= 5 milliseconds
99.87% <= 6 milliseconds
99.94% <= 7 milliseconds
99.97% <= 8 milliseconds
99.98% <= 9 milliseconds
100.00% <= 10 milliseconds
33400.13 requests per second
====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 7.76 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
0.01% <= 1 milliseconds
0.16% <= 2 milliseconds
7.91% <= 3 milliseconds
52.84% <= 4 milliseconds
81.97% <= 5 milliseconds
93.00% <= 6 milliseconds
97.40% <= 7 milliseconds
98.54% <= 8 milliseconds
99.03% <= 9 milliseconds
99.36% <= 10 milliseconds
99.59% <= 11 milliseconds
99.70% <= 12 milliseconds
99.78% <= 13 milliseconds
99.84% <= 14 milliseconds
99.90% <= 15 milliseconds
99.94% <= 16 milliseconds
99.96% <= 17 milliseconds
99.97% <= 18 milliseconds
99.98% <= 19 milliseconds
99.99% <= 20 milliseconds
99.99% <= 21 milliseconds
100.00% <= 22 milliseconds
12894.91 requests per second
====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 11.93 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
0.00% <= 1 milliseconds
0.02% <= 2 milliseconds
0.12% <= 3 milliseconds
2.43% <= 4 milliseconds
20.42% <= 5 milliseconds
49.68% <= 6 milliseconds
69.88% <= 7 milliseconds
85.24% <= 8 milliseconds
94.16% <= 9 milliseconds
97.79% <= 10 milliseconds
98.70% <= 11 milliseconds
99.03% <= 12 milliseconds
99.26% <= 13 milliseconds
99.44% <= 14 milliseconds
99.57% <= 15 milliseconds
99.68% <= 16 milliseconds
99.78% <= 17 milliseconds
99.85% <= 18 milliseconds
99.90% <= 19 milliseconds
99.93% <= 20 milliseconds
99.95% <= 21 milliseconds
99.96% <= 22 milliseconds
99.97% <= 23 milliseconds
99.98% <= 24 milliseconds
99.98% <= 26 milliseconds
99.98% <= 27 milliseconds
99.99% <= 28 milliseconds
100.00% <= 29 milliseconds
100.00% <= 29 milliseconds
8385.74 requests per second
====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 14.80 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
0.00% <= 1 milliseconds
0.02% <= 2 milliseconds
0.04% <= 3 milliseconds
0.20% <= 4 milliseconds
2.88% <= 5 milliseconds
15.84% <= 6 milliseconds
40.24% <= 7 milliseconds
61.00% <= 8 milliseconds
74.88% <= 9 milliseconds
85.65% <= 10 milliseconds
93.36% <= 11 milliseconds
97.13% <= 12 milliseconds
98.37% <= 13 milliseconds
98.87% <= 14 milliseconds
99.14% <= 15 milliseconds
99.32% <= 16 milliseconds
99.42% <= 17 milliseconds
99.50% <= 18 milliseconds
99.59% <= 19 milliseconds
99.65% <= 20 milliseconds
99.69% <= 21 milliseconds
99.74% <= 22 milliseconds
99.78% <= 23 milliseconds
99.82% <= 24 milliseconds
99.86% <= 25 milliseconds
99.88% <= 26 milliseconds
99.90% <= 27 milliseconds
99.92% <= 28 milliseconds
99.94% <= 29 milliseconds
99.95% <= 30 milliseconds
99.96% <= 31 milliseconds
99.97% <= 32 milliseconds
99.98% <= 33 milliseconds
99.98% <= 34 milliseconds
99.99% <= 35 milliseconds
100.00% <= 36 milliseconds
100.00% <= 36 milliseconds
6755.39 requests per second
====== MSET (10 keys) ======
  100000 requests completed in 1.76 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1
53.95% <= 1 milliseconds
93.05% <= 2 milliseconds
99.56% <= 3 milliseconds
99.95% <= 4 milliseconds
100.00% <= 4 milliseconds
56915.20 requests per second

2、测试存取大小为100字节的数据包的性能

redis-benchmark -h 172.16.254.124 -p 7004 -c -q -d 100

====== PING_INLINE ======
  100000 requests completed in 6.18 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.17% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 3 milliseconds
16191.71 requests per second
====== PING_BULK ======
  100000 requests completed in 6.59 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.18% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
15169.90 requests per second
====== SET ======
  100000 requests completed in 5.67 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.45% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
17624.25 requests per second
====== GET ======
  100000 requests completed in 5.71 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.71% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
17500.88 requests per second
====== INCR ======
  100000 requests completed in 8.22 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
98.28% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
12171.37 requests per second
====== LPUSH ======
  100000 requests completed in 8.99 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
98.91% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 7 milliseconds
11117.29 requests per second
====== RPUSH ======
  100000 requests completed in 9.85 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
98.70% <= 1 milliseconds
99.97% <= 2 milliseconds
100.00% <= 6 milliseconds
10151.25 requests per second
====== LPOP ======
  100000 requests completed in 8.39 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.36% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 4 milliseconds
100.00% <= 5 milliseconds
11920.37 requests per second
====== RPOP ======
  100000 requests completed in 8.11 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.45% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 4 milliseconds
100.00% <= 6 milliseconds
12325.90 requests per second
====== SADD ======
  100000 requests completed in 4.07 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.94% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 4 milliseconds
24576.06 requests per second
====== HSET ======
  100000 requests completed in 5.63 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.62% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 3 milliseconds
17752.53 requests per second
====== SPOP ======
  100000 requests completed in 7.51 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
98.68% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 5 milliseconds
13306.72 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 9.73 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
98.99% <= 1 milliseconds
99.96% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 5 milliseconds
100.00% <= 6 milliseconds
100.00% <= 18 milliseconds
10280.66 requests per second
====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 9.55 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.37% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 3 milliseconds
10474.50 requests per second
====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 26.23 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
95.12% <= 1 milliseconds
99.97% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 3 milliseconds
3811.99 requests per second
====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 31.84 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
97.06% <= 1 milliseconds
99.97% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
3141.00 requests per second
====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 44.52 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
94.49% <= 1 milliseconds
99.96% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 5 milliseconds
2246.33 requests per second
====== MSET (10 keys) ======
  100000 requests completed in 6.29 seconds
  0 parallel clients
  100 bytes payload
  keep alive: 1
99.46% <= 1 milliseconds
99.99% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 3 milliseconds
15893.20 requests per second

3、对3000字节的数据进行set和get的操作

redis-benchmark -h 172.16.254.124 -p 7004 -c -t set,get -n 100000 -q -d 3000

====== set,get -n 100000 -q -d 3000 ======
  100000 requests completed in 6.54 seconds
  0 parallel clients
  3 bytes payload
  keep alive: 1
99.18% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 3 milliseconds
15295.20 requests per second

4、测试某些值的存取功能 

redis-benchmark -h 172.16.254.124 -p 7004 -c -n 100000 -q script load "redis.call('set','foo','bar')"

====== 100000 -q script load redis.call('set','foo','bar') ======
  100000 requests completed in 8.57 seconds
  0 parallel clients
  3 bytes payload
  keep alive: 1
97.98% <= 1 milliseconds
99.96% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 3 milliseconds
11664.53 requests per second
StevenBeijing
关注
Redis redis-benchmark 压测结果
MyySophia的博客
07-22 565
redis-benchmark benchmark]# redis-benchmark -h 127.0.0.1 -p 6382 -c 500 -n 200000 -nTotal number of requests (default 100000) -c 500个并发连接， 其他参数请通过 redis-benchmark --help 以下是测试执行的结果 ====== PING_INLINE ====== 200000 requests completed in 2....
使用 redis-benchmark 进行性能测试的详细指南
maply的博客
01-10 2517
`redis-benchmark` 是 Redis 自带的一款性能测试工具，用于模拟不同的客户端请求场景，帮助开发者评估 Redis 在特定硬件、配置和负载下的性能。无论是新部署的 Redis 实例还是优化后的环境，`redis-benchmark` 都可以提供基准测试数据，以衡量性能的变化。
Redis集群性能测试分析
10-16
Redis是一个非关系型数据库，属于内存级数据库。但是由于数据量的不断增大，单机的Redis物理内存远远无法满足大数据的需要，因此需要搭建分布式的Redis，可以动态扩展内存，弥补单机Redis物理内存不够的缺点。本次测试旨在对Redis各方面性能有深入的了解，为今后的工作打好基础。本次实验的目的主要是搭建Redis Cluster和TwemProxy Redis两种集群，分别对其进行性能测试，测试出集群性能的拐点，找出性能的瓶颈有哪些，并对两套集群进行比较，以便于在不同业务场景下择优选择。
高可用Redis集群：从测试到实战的完整方案
最新发布
gitblog_00680的博客
09-24 599
Redis集群（Redis Cluster）作为分布式数据库解决方案，通过分片存储和自动故障转移实现高可用。但生产环境中频繁出现的**数据不一致**、**脑裂**和**恢复超时**问题，往往源于测试阶段对极端场景覆盖不足。本文将系统讲解Redis官方集群测试框架的实现原理，帮助你构建覆盖99%故障场景的测试体系。 ## 测试框架核心组件解析 Redis集群测试套件位于[tests/cluster...
用memtier-benchmark测试Redis集群版性能
谢白羽
08-11 3628
文章目录一、memtier-benchmark安装步骤法一法二二、memtier-benchmark测试命令说明及常用测试选项2.1 连接和通用选项2.2 测试选项2.3 对象选项2.4 导入数据选项2.5 测试键选项2.6 等待选项三、伪随机数据、高斯访问模式和范围操作3.1 伪随机数据3.2 高斯访问模式（也叫正态分布）3.3 范围操作四、测试用例展示4.1 定制测试4.2 快速测试五、redis-benchmark和memtier_benchmark的差异 一、memtier-benchmark安装步
redis 性能测试
12-10
wrapper 包装, 使用jedis 测试redis 读性能
Redis客户端性能压测工具 redis-benchmark是否支持集群模式
a1510841693的博客
07-27 2560
Redis客户端性能压测工具redis-benchmark支持集群模式的官网代码提交记录：https://github.com/redis/redis/commit/dfd3cc5f783630c1611ff2922f6f1f1171be44f5#diff-f37c3eacb5f6ac27e8fa820f102e8b57f0f33c7b46e5ef2ba46b8ad8a56c86a6 Redis客户端性能压测工具redis-benchmark对集群模式支持的说明： https://github.co
Redis性能测试——redis-benchmark使用教程
热门推荐
yangcs2009的专栏
03-02 3万+
谨以此作为读书摘要，无它，唯以后快速查阅 Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求。 （类似于 Apache ab 程序）。你可以使用 redis-benchmark -h 来查看基准参数。 以下参数被支持： Usage: redis-benchmark [-h ] [-p ] [-c ] [-n [-k ] -h
精选资源
redis-7.2-x64-for-windows-bin.zip
09-04
10. **redis-benchmark.exe**: 这是Redis的性能测试工具，可以用来衡量Redis服务器的吞吐量和响应时间，帮助优化配置和硬件选择。 11. **data**: 这个目录可能包含Redis默认的数据存储位置，用户可以将Redis的数据...
精选资源
redis-windows-7.2.4.zip（免安装，解压即可使用）
06-22
4. **redis-benchmark.exe**：性能测试工具，可以用来评估Redis服务器的读写速度和处理能力。 5. **其他辅助文件**：如日志文件、帮助文档等，帮助管理和理解Redis的运行状态。 在Windows环境下使用Redis，首先需要...
精选资源
redis-6.2.14-win-amd64
05-22
5. 结合主从复制和哨兵（Sentinel）系统，构建高可用的Redis集群。 在Windows环境下，Redis提供了一个高效且灵活的数据存储解决方案。通过了解和熟练掌握其核心概念和使用方法，开发者可以充分利用Redis的特性来...
Redis 性能测试
12-16
Redis 性能测试 Redis 性能测试是通过同时执行多个命令实现的。 语法 redis 性能测试的基本命令如下： redis-benchmark [option] [option value] 注意：该命令是在 redis 的目录下执行的，而不是 redis 客户端的内部指令。 实例 以下实例同时执行 10000 个请求来检测性能： $ redis-benchmark -n 10000 -q PING_INLINE: 141043.72 requests per second PING_BULK: 142857.14 requests per second SET: 141442
redis集群测试
qq_27164239的博客
07-15 1798
redis集群测试
Redis集群性能测试工具redis-benchmark
Flyer的后花园
04-25 1万+
使用本文之前 比如集群在某个机器上7001端口有redis节点记得使用ip 端口 比如如下redis-benchmark  -h 10.166.15.36 -p 7001 -n 100000 -q script load "redis.call('set','foo','一二三四五六七八九十')"./redis-benchmark  -h 10.166.15.36 -p 7001  -q -n 1...
Redis集群
Drizzt0878的专栏
03-31 4032
这段时间项目需要对缓存进行集群，以下通过对redis集群研究与测试，对比直接采用单机内存缓存方式的性能。文章记录本人学习与实践redis集群的一些步骤与测试。包括redis集群研究与测试，分析其的可用性、可靠性、可运维性以及性能等方面。
Redis-benchmark测试Redis性能
weixin_30767921的博客
05-19 173
Redis-benchmark是官方自带的Redis性能测试工具，可以有效的测试Redis服务的性能。 使用说明如下： Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>] -h <ho...
redis-benchmark性能测试
Massimo__JAVA的博客
11-15 345
redis-benchmark性能测试
redis-benchchmark性能测试
qq_51447436的博客
11-11 4893
redis-benchchmark性能测试
redis-benchmark测试防范
04-03
<think>好的，我现在需要回答用户关于如何使用redis-benchmark进行性能测试以及注意事项的问题。首先，我得回顾一下用户提供的引用内容，看看里面有哪些关键信息可以利用。 用户提供的引用中提到了redis-benchmark的基本命令参数，比如-c（并发数）、-n（总请求数）、-q（安静模式）、-r（随机键数量）等。还有提到第三方工具如YCSB和redisbench，但用户主要关注的是redis-benchmark本身，所以可能需要先介绍基本用法，再提到其他工具作为补充。 接下来，引用里还提到了管道输出和使用grep过滤结果，这说明在运行基准测试时，用户可能需要处理大量输出数据，这时候使用管道和grep会很有帮助。另外，关于延迟监控的部分，用户可以使用--latency选项来检查Redis实例的延迟情况，这也应该包含在注意事项里。 用户的问题包括使用方法和最佳实践，所以需要分步骤解释。首先，我需要介绍基本命令格式，然后列举常用参数并解释每个参数的作用。例如，-h指定主机，-p指定端口，-c设置并发连接数，-n设置总请求数，-k是否使用keepalive，-t选择要测试的命令，-q启用安静模式，-r生成随机键，-d设置数据大小，-P使用管道，-l循环测试，以及--csv输出CSV格式。这些参数都需要详细说明，让用户知道如何组合使用。 然后，在最佳实践部分，需要根据引用中的信息提出建议。比如，逐步增加并发数，使用随机键避免缓存影响，模拟真实数据大小，结合管道提升吞吐量，监控系统资源，多次测试取平均值，以及结合其他工具如redis-cli的延迟检测。此外，注意事项中要提到网络影响、避免在生产环境测试、结果分析方法和版本兼容性等问题。 需要注意的是，用户可能不太清楚某些参数的具体影响，比如为什么使用-r或者-P，这时候需要用简单的例子说明。例如，使用-r 10000可以生成1万到10万的键，避免所有请求都集中在同一个键上，从而更真实地模拟实际场景。 另外，引用中提到了集群测试的局限性，即redis-benchmark不支持集群模式，这时候可以建议使用第三方工具如redisbench来进行集群测试，并附上相关下载链接，但用户主要问题还是关于redis-benchmark本身，所以这部分可能放在注意事项或扩展建议里。 最后，确保回答结构清晰，分步骤讲解，参数用列表展示，示例命令用代码块，注意事项和最佳实践分点说明。同时，引用中的信息需要正确标注，例如提到性能测试指标时引用[^1]，集群测试工具引用[^2]，参数说明引用[^3]，延迟检测引用[^4]。 现在，我需要把这些思考整理成一个连贯的回答，确保每个部分都覆盖到，并且符合用户要求的格式，比如行内公式用$...$，独立公式用$$...$$，但在这个问题中可能用不上数学公式，但需要留意是否有相关内容。此外，生成的相关问题需要与主题相关，比如如何解读结果、优化性能、集群测试工具比较等。</think>### 如何使用 redis-benchmark 进行性能测试及注意事项 #### 一、redis-benchmark 基础用法 `redis-benchmark` 是 Redis 官方自带的性能测试工具，用于模拟客户端并发请求并测量 Redis 服务器的吞吐量和延迟。 **基本命令格式**： ```bash redis-benchmark [参数] [命令] ``` #### 二、核心参数详解 1. **连接配置** - `-h <host>`：指定 Redis 服务器 IP（默认 `127.0.0.1`） - `-p <port>`：指定端口（默认 `6379`） 2. **负载配置** - `-c <clients>`：并发连接数（默认 50） - `-n <requests>`：总请求数（默认 100000） - `-k <1/0>`：是否启用 Keepalive（默认 1，启用） 3. **测试命令选择** - `-t <command>`：指定要测试的命令（如 `SET,GET,LPUSH`），默认测试全部命令 - 示例：仅测试 `SET` 和 `GET` ```bash redis-benchmark -t SET,GET -n 10000 ``` 4. **输出控制** - `-q`：安静模式，仅输出每秒请求数（QPS）[^3] - `-r <keyspace>`：生成随机键范围（如 `-r 10000` 表示键名从 1 到 10000） - `--csv`：结果以 CSV 格式输出 5. **数据配置** - `-d <size>`：SET/GET 值的数据大小（默认 3 字节） ```bash redis-benchmark -d 1024 # 测试 1KB 数据 ``` 6. **高级特性** - `-P <num>`：使用管道（Pipeline）批量发送请求（提升吞吐量） - `-l`：循环测试，持续运行直到手动停止 #### 三、性能测试最佳实践 1. **逐步增加并发数** 从低并发（如 `-c 50`）开始，逐步增加以观察性能拐点。例如： ```bash redis-benchmark -c 50 -n 100000 && redis-benchmark -c 100 -n 200000 ``` 2. **使用随机键避免缓存影响** 添加 `-r 100000` 参数，避免重复操作同一键导致内存缓存优化失真。 3. **模拟真实数据大小** 根据业务场景设置 `-d`，如缓存图片时测试 `-d 4096`（4KB）。 4. **结合管道提升吞吐量** 使用 `-P 10` 批量发送请求，减少网络往返开销： ```bash redis-benchmark -P 10 -q ``` 5. **监控系统资源** 测试时通过 `top` 或 `htop` 观察 Redis 服务器的 CPU、内存和网络占用。 6. **多次测试取平均值** 运行 3-5 次测试，排除偶然波动。 7. **结合延迟检测工具** 使用 `redis-cli --latency` 实时监控请求延迟分布： ```bash redis-cli -h 192.168.1.100 --latency ``` #### 四、注意事项 1. **网络影响** 避免在跨机房或高延迟网络中测试，建议在本地或同机房执行。 2. **生产环境慎用** `redis-benchmark` 可能对生产环境造成负载压力，建议在测试环境运行。 3. **结果分析** 关注 `requests per second`（QPS）和 `latency`（延迟）指标，结合业务需求判断是否达标。 4. **集群测试限制** `redis-benchmark` 不支持原生集群模式，需使用第三方工具如 `redisbench` 进行集群基准测试。 5. **版本兼容性** 确保测试工具与 Redis 服务器版本一致，避免协议不兼容问题。 #### 五、完整示例 ```bash # 测试远端 Redis 的 SET/GET 命令，使用 100 并发、10 万请求、1KB 数据、随机键 redis-benchmark -h 192.168.1.100 -p 6379 -t SET,GET -c 100 -n 100000 -d 1024 -r 10000 --csv ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值