性能测试

测试 Redis 实例的性能可能是一项复杂的任务。 Redis 实例的性能可能因客户端数、数据值的大小以及是否正在使用管道传输等参数而有所不同。 优化吞吐量或延迟之间可能也需要权衡。

幸运的是，有几种工具可以更轻松地对 Redis 进行基准测试。 两个最常用的工具是 redis-benchmark 和 memtier-benchmark。 本文重点介绍 redis-benchmark。

如何使用 redis-benchmark 实用工具

1. 将开源 Redis 服务器安装到可用于测试的客户端 VM。 redis-benchmark 实用工具内置于开源 Redis 发行版。 有关如何安装开源映像的说明，请参阅 Redis 文档。

2. 用于测试的客户端 VM 应与 Azure Redis 缓存实例位于同一区域。

3. 确保所用客户端 VM 至少与正在测试的缓存拥有相同的计算和带宽容量。

4. 配置网络隔离和防火墙设置，确保客户端 VM 能够访问你的 Azure Cache for Redis 实例。

5. 如果在你的缓存实例上使用 TLS/SSL，则需要将 --tls 参数添加到 redis-benchmark 命令，或使用 stunnel 等代理。

6. 默认情况下，Redis-benchmark 使用端口 6379。 使用 -p 参数替代此设置。 如果你在使用 SSL/TLS（端口 6380），则需要使用 -p。

7. 如果你在使用的是使用聚类分析的 Azure Cache for Redis 实例，则需要将 --cluster 参数添加到 redis-benchmark 命令。

8. 从 VM 的 CLI 或 shell 启动 redis-benchmark。 有关如何配置和运行该工具的说明，请参阅 redis-benchmark 文档 和 redis-benchmark 示例部分。

基准测试建议

• 请勿仅在稳定状态条件下对缓存进行性能测试。 还需要按照故障转移条件进行测试，并在测试期间测量缓存中的 CPU/服务器负载。 可以通过重新启动主节点来启动故障转移。 通过在故障转移条件下进行测试，可了解应用程序在故障转移条件下的吞吐量和延迟情况。 故障转移可能在更新期间或计划外事件期间发生。 理想情况下，即使是在故障转移期间，CPU/服务器负载峰值也应该不会很高（例如超过 80%），因为这可能会影响性能。

• 请考虑使用高级层 Azure Cache for Redis 实例。 这些缓存大小具有更好的网络延迟和吞吐量，因为它们是在更好的硬件上运行的。

• 基于开源 Redis 的层（例如 Standard 和 Premium）只能为每个分片的 Redis 进程使用一个 vCPU。

• 使用 TLS/SSL 会降低吞吐量性能，下表中的基准测试数据示例清楚地阐释了这一点。

• 即使 Redis 服务器是单线程服务器，纵向扩展往往会提高吞吐量性能。 系统进程可以使用额外的 vCPU，而不是共享 Redis 进程正在使用的 vCPU。

• 在 Premium 层上，通常建议在纵向扩展之前横向扩展（聚类分析）。 群集允许 Redis 服务器通过对数据进行分片来使用更多 vCPU。 在这种情况下，添加分片时，吞吐量应大致呈线性增长。

Redis 基准示例

测试前的设置：准备好缓存实例以及测试延迟和吞吐量所需的数据：

redis-benchmark -h yourcache.redis.cache.chinacloudapi.cn -a yourAccesskey -t SET -n 10 -d 1024

测试延迟：使用 1k 有效负载测试 GET 请求：

redis-benchmark -h yourcache.redis.cache.chinacloudapi.cn -a yourAccesskey -t GET -d 1024 -P 50 -c 4

测试吞吐量：使用 1k 有效负载测试管道 GET 请求：

redis-benchmark -h yourcache.redis.cache.chinacloudapi.cn -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

若要使用 TLS 测试 Basic、Standard 或 Premium 层缓存的吞吐量：有效负载为 1k 的管道 GET 请求：

redis-benchmark -h yourcache.redis.cache.chinacloudapi.cn -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

性能基准数据示例

下表显示了在测试各种大小的“标准”和“高级”缓存时观察到的最大吞吐量值。 我们针对 Azure Cache for Redis 终结点使用了来自 IaaS Azure VM 的 redis-benchmark。 吞吐量数字仅适用于 GET 命令。 通常，SET 命令的吞吐量较低。 这些数字针对吞吐量进行了优化。 在可接受的延迟条件下，实际吞吐量可能会偏低。

以下配置用于对基本层、标准和高级层的吞吐量进行基准测试：

redis-benchmark -h yourcache.redis.cache.chinacloudapi.cn -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

标准层

实例	大小	vCPU	预期的网络带宽 (Mbps)	不带 SSL 的每秒 GET 请求数（1-kB 值大小）	带 SSL 的每秒 GET 请求数（1-kB 值大小）
C0	250 MB	共享	100	15,000	7,500
C1	1 GB	1	500	38,000	20,720
C2	2.5 GB	2	500	41,000	37,000
C3	6 GB	4	1000	100,000	90,000
C4	13 GB	2	500	60,000	55,000
C5	26 GB	4	1,000	102,000	93,000
C6	53 GB	8	2,000	126,000	120,000

高级层

实例	大小	vCPU	预期的网络带宽 (Mbps)	不带 SSL 的每秒 GET 请求数（1-kB 值大小）	带 SSL 的每秒 GET 请求数（1-kB 值大小）
P1	6 GB	2	1,500	180,000	172,000
P2	13 GB	4	3,000	350,000	341,000
P3	26 GB	4	3,000	350,000	341,000
P4	53 GB	8	6,000	400,000	373,000
P5	120 GB	32	6,000	400,000	373,000

后续步骤

• 开发
• Azure Cache for Redis 开发的常见问题解答
• Azure Cache for Redis 的故障转移和修补