正文

Redis 自带了一个 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求，你可以使用 redis-benchmark -h 来查看基准参数。

语法

Redis 性能测试的基本命令如下：

redis-benchmark [option] [option value]

Redis 性能测试工具可选参数如下所示： 

 

测试 

在本地部署 Redis 容器后，进行测试。如何部署 Redis 容器第一次已经讲过啦！所以就不重新讲解啦！

 进行性能测试  

测试结果有很多。所以只挑了 SET 和 GET 方法

 讲解：10个并发数，请求100次，在0.02秒内完成，每次发送3个字节， 只有1台 Redis 服务器节点连接情况下操作。

从上面可以看出 100 个 SET 请求在0.02秒内完成，最后请求都是在4秒内完成，每秒能处理  5263.16 个请求。

100 个 GET 请求在0.0秒内完成，最后请求都是在0秒内完成，每秒能处理 33333.33 个请求。

精简快速测试

语法：redis-benchmark -h localhost -p 6379 -a dangerous -c 10 -n 100 -q

  

影响 Redis 性能的因素

有几个因素直接决定 Redis 的性能。它们能够改变基准测试的结果， 所以我们必须注意到它们。一般情况下，Redis 默认参数已经可以提供足够的性能， 不需要调优。

• 网络带宽和延迟通常是最大短板。建议在基准测试之前使用 ping 来检查服务端到客户端的延迟。根据带宽，可以计算出最大吞吐量。 比如将 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么实际需要 3.2 Gbits/s 的带宽，所以需要 10 GBits/s 网络连接， 1 Gbits/s 是不够的。 在很多线上服务中，Redis 吞吐会先被网络带宽限制住，而不是 CPU。 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。
• CPU 是另外一个重要的影响因素，由于是单线程模型，Redis 更喜欢大缓存快速 CPU， 而不是多核。这种场景下面，比较推荐 Intel CPU。AMD CPU 可能只有 Intel CPU 的一半性能（通过对 Nehalem EP/Westmere EP/Sandy 平台的对比）。 当其他条件相当时候，CPU 就成了 redis-benchmark 的限制因素。
• 在小对象存取时候，内存速度和带宽看上去不是很重要，但是对大对象（> 10 KB）， 它就变得重要起来。不过通常情况下面，倒不至于为了优化 Redis 而购买更高性能的内存模块。
• Redis 在 VM 上会变慢。虚拟化对普通操作会有额外的消耗，Redis 对系统调用和网络终端不会有太多的 overhead。建议把 Redis 运行在物理机器上， 特别是当你很在意延迟时候。在最先进的虚拟化设备（VMWare）上面，redis-benchmark 的测试结果比物理机器上慢了一倍，很多 CPU 时间被消费在系统调用和中断上面。
• 如果服务器和客户端都运行在同一个机器上面，那么 TCP/IP loopback 和 unix domain sockets 都可以使用。对 Linux 来说，使用 unix socket 可以比 TCP/IP loopback 快 50%。 默认 redis-benchmark 是使用 TCP/IP loopback。 当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。
• 当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。
• 当使用网络连接时，并且以太网网数据包在 1500 bytes 以下时， 将多条命令包装成 pipelining 可以大大提高效率。事实上，处理 10 bytes，100 bytes， 1000 bytes 的请求时候，吞吐量是差不多的，

  其他需要注意的点

• 任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。

• 一个好的实践是尽可能在隔离的硬件上面测试。如果没法实现，那就需要检测 benchmark 没有受其他服务器活动影响。
• 有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 CPU 分配策略。 这种策略可以在 OS 层面配置。有些 CPU 型号相对其他能更好的调整 CPU 负载。 为了达到可重现的测试结果，最好在做基准测试时候设定 CPU 到最高使用限制。
• 一个重要因素是配置尽可能大内存，千万不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的内存限制。
• 如果你计划在基准测试时候使用 RDB 或 AOF，请注意不要让系统同时有其他 I/O 操作。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。
• 将 Redis 日志级别设置到 warning 或者 notice。避免将日志放到远程文件系统。
• 避免使用检测工具，它们会影响基准测试结果。使用 INFO 来查看服务器状态没问题， 但是使用 MONITOR 将大大影响测试准确度。

参考：REDIS benchmarks -- Redis中文资料站 -- Redis中国用户组（CRUG）