redis 性能测试

本文详细记录了使用redis-benchmark工具进行的Redis性能测试结果,包括PING、SET、GET、INCR等命令的响应时间和每秒处理请求的数量,展示了在不同负载下的Redis性能表现。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Redis 性能测试

指定 10000 个请求:

> redis-benchmark -n 10000  -q
====== PING_INLINE ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.91% <= 1 milliseconds
99.98% <= 2 milliseconds
100.00% <= 2 milliseconds
70921.98 requests per second

====== PING_BULK ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.28% <= 1 milliseconds
100.00% <= 1 milliseconds
68965.52 requests per second

====== SET ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.54% <= 1 milliseconds
100.00% <= 1 milliseconds
70921.98 requests per second

====== GET ======
  10000 requests completed in 0.16 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

97.85% <= 1 milliseconds
99.58% <= 2 milliseconds
99.93% <= 3 milliseconds
100.00% <= 3 milliseconds
64102.56 requests per second

====== INCR ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.48% <= 1 milliseconds
100.00% <= 1 milliseconds
69444.45 requests per second

====== LPUSH ======
  10000 requests completed in 0.15 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.74% <= 1 milliseconds
100.00% <= 1 milliseconds
68493.15 requests per second

====== RPUSH ======
  10000 requests completed in 0.15 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.60% <= 1 milliseconds
100.00% <= 1 milliseconds
67567.57 requests per second

====== LPOP ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.73% <= 1 milliseconds
100.00% <= 1 milliseconds
70921.98 requests per second

====== RPOP ======
  10000 requests completed in 0.15 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.57% <= 1 milliseconds
100.00% <= 1 milliseconds
67114.09 requests per second

====== SADD ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.72% <= 1 milliseconds
100.00% <= 1 milliseconds
69930.07 requests per second

====== HSET ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.43% <= 1 milliseconds
100.00% <= 1 milliseconds
68965.52 requests per second

====== SPOP ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.00% <= 1 milliseconds
100.00% <= 1 milliseconds
70422.53 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.30% <= 1 milliseconds
100.00% <= 1 milliseconds
69930.07 requests per second

====== LRANGE_100 (first 100 elements) ======
  10000 requests completed in 0.22 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

96.42% <= 1 milliseconds
100.00% <= 1 milliseconds
46296.30 requests per second

====== LRANGE_300 (first 300 elements) ======
  10000 requests completed in 0.44 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

15.69% <= 1 milliseconds
99.41% <= 2 milliseconds
99.96% <= 3 milliseconds
100.00% <= 3 milliseconds
22831.05 requests per second

====== LRANGE_500 (first 450 elements) ======
  10000 requests completed in 0.58 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.12% <= 1 milliseconds
98.48% <= 2 milliseconds
99.66% <= 3 milliseconds
99.91% <= 4 milliseconds
100.00% <= 4 milliseconds
17301.04 requests per second

====== LRANGE_600 (first 600 elements) ======
  10000 requests completed in 0.73 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.03% <= 1 milliseconds
85.95% <= 2 milliseconds
99.36% <= 3 milliseconds
99.89% <= 4 milliseconds
100.00% <= 4 milliseconds
13661.20 requests per second

====== MSET (10 keys) ======
  10000 requests completed in 0.14 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.70% <= 1 milliseconds
100.00% <= 1 milliseconds
69930.07 requests per second

指令参数如下:

1-h指定服务器主机名127.0.0.1
2-p指定服务器端口6379
3-s指定服务器 socket
4-c指定并发连接数50
5-n指定请求数10000
6-d以字节的形式指定 SET/GET 值的数据大小2
7-k1=keep alive 0=reconnect1
8-rSET/GET/INCR 使用随机 key, SADD 使用随机值
9-P通过管道传输 请求1
10-q强制退出 redis。仅显示 query/sec 值
11–csv以 CSV 格式输出
12-l生成循环,永久执行测试
13-t仅运行以逗号分隔的测试命令列表。
14-IIdle 模式。仅打开 N 个 idle 连接并等待。
<think>好的,我现在需要帮助用户了解Redis性能测试中的应用及具体测试步骤。用户之前已经询问过Redis的基本概念和在企业中的角色,以及性能测试中的用途,现在他们更关注具体的测试步骤。我需要结合之前的回答和提供的引用内容来构建一个清晰的步骤指南。首先,用户提到了引用[1]中的redis-benchmark工具,这是关键点。我需要详细说明如何使用这个工具,包括参数设置和示例命令。引用[2]中提到了Redis安装后的bin目录下的工具,这里可能需要确认测试前的环境准备步骤,比如确保redis-server和redis-benchmark已正确安装。接下来,用户之前的回答中提到了作为被测对象和测试工具组件的用途,现在需要将这些转化为具体的测试步骤。比如基准测试、容量测试、高可用测试等,可能需要分步骤详细说明每个测试类型的具体操作方法,并引用相应的引用内容。另外,用户可能还需要了解如何分析测试结果,比如使用INFO命令获取指标,或者监控内存碎片问题。引用[3]提到了TLS对性能的影响,虽然用户当前的问题可能不涉及,但需要注意是否需要提及性能优化的考虑因素。需要确保回答结构清晰,分点列出测试步骤,每个步骤包含具体命令和示例,并正确引用提供的引用资料。同时,要避免使用Markdown格式,保持自然的中文口语化,但最终答案需要符合用户的结构要求,使用标题、代码块、公式等。最后,生成相关问题时要基于用户之前的问题和当前内容,比如高可用架构的实现、数据结构的选择、监控工具的使用等,确保问题相关且有深度。</think>### Redis性能测试步骤(软件测试工程师视角) #### 1. **测试环境准备** - 安装Redis服务端和基准测试工具(`redis-server`和`redis-benchmark`位于`/usr/local/redis/bin`目录)[^2] - 启动Redis服务: ```bash ./redis-server /path/to/redis.conf ``` #### 2. **基准测试参数设置** 使用`redis-benchmark`工具模拟并发请求,关键参数: ```bash redis-benchmark -h 127.0.0.1 -p 6379 \ -n 100000 -c 50 \ -t get,set \ --threads 4 ``` - `-n`: 总请求数 - `-c`: 并发客户端数 - `-t`: 测试命令类型 - `--threads`: 多线程模式(提升吞吐量)[^1] #### 3. **测试类型与步骤** | 测试类型 | 执行步骤 | |-----------------|--------------------------------------------------------------------------| | **吞吐量测试** | 观察每秒请求数(QPS),例如:<br>`redis-benchmark -n 100000 -c 100` | | **延迟测试** | 添加`--latency`参数分析响应时间分布:<br>`redis-benchmark --latency` | | **持久化测试** | 启用RDB/AOF后,测试数据写入性能与恢复速度 | | **集群测试** | 对Redis Cluster执行跨节点操作,验证分片性能[^3] | #### 4. **性能指标监控** - 通过`redis-cli`获取实时状态: ```bash redis-cli info stats | grep "instantaneous_ops_per_sec" ``` - 内存利用率计算公式: $$ \text{内存使用率} = \frac{\text{used\_memory}}{\text{maxmemory}} \times 100\% $$ #### 5. **结果分析与优化** - 对比不同参数下的QPS和延迟曲线 - 识别瓶颈(如CPU、网络带宽或内存碎片) - 调整`redis.conf`配置(例如`maxclients`、`timeout`) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值