你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
性能测试
测试 Redis 实例的性能可能是一项复杂的任务。 Redis 实例的性能可能因客户端数、数据值的大小以及是否正在使用管道传输等参数而有所不同。 优化吞吐量或延迟之间可能也需要权衡。
幸运的是，有几种工具可以更轻松地对 Redis 进行基准测试。 两个最常用的工具是 redis-benchmark 和 memtier-benchmark。 本文重点介绍 redis-benchmark。
如何使用 redis-benchmark 实用工具
将开源 Redis 服务器安装到可用于测试的客户端虚拟机 (VM)。 redis-benchmark 实用工具内置于开源 Redis 发行版。 有关如何安装开源映像的说明，请参阅 Redis 文档。
用于测试的客户端 VM 应与 Azure Redis 缓存实例位于同一区域。
确保所用客户端 VM 至少与正在测试的缓存拥有相同的计算和带宽容量。
如果在你的缓存实例上使用 TLS/SSL，则需要将
--tls参数添加到 redis-benchmark 命令，或使用 stunnel 等代理。默认情况下，
Redis-benchmark使用端口 6379。 使用-p参数替代此设置。 如果你在使用 SSL/TLS（端口 6380），或者在使用 Enterprise 层（端口 10000），则需要使用-p。如果你在使用的是使用聚类分析的 Azure Cache for Redis 实例，则需要将
--cluster参数添加到redis-benchmark命令。 使用聚类分析的企业层缓存可以被视为非聚集缓存，不需要此设置。从 VM 的 CLI 或 shell 启动
redis-benchmark。 有关如何配置和运行该工具的说明，请参阅 redis-benchmark 文档 和 redis-benchmark 示例部分。
基准测试建议
请勿仅在稳定状态条件下对缓存进行性能测试。 还需要按照故障转移条件进行测试，并在测试期间测量缓存中的 CPU/服务器负载。 可以通过重新启动主节点来启动故障转移。 通过在故障转移条件下进行测试，可了解应用程序在故障转移条件下的吞吐量和延迟情况。 故障转移可能在更新期间或计划外事件期间发生。 理想情况下，即使是在故障转移期间，CPU/服务器负载峰值也应该不会很高（例如超过 80%），因为这可能会影响性能。
请考虑使用 Enterprise 和 Premium 层 Azure Cache for Redis 实例。 这些缓存大小具有更好的网络延迟和吞吐量，因为它们是在更好的硬件上运行的。
Enterprise 层通常具有最佳性能，因为 Redis Enterprise 允许核心 Redis 进程利用多个 vCPU。 基于开源 Redis 的层（例如 Standard 和 Premium）只能为每个分片的 Redis 进程使用一个 vCPU。
Enterprise Flash 层的基准测试可能很困难，因为有些键存储在 DRAM 上，而有些键存储在 NVMe 闪存磁盘上。 DRAM 基准上的键几乎与 Enterprise 层实例一样快，但 NVMe 闪存盘上的键速度较慢。 由于 Enterprise Flash 层会智能地将最常用的键放入 DRAM，请确保基准配置符合预期的实际使用情况。 请考虑使用
-r参数随机化要访问的键。使用 TLS/SSL 会降低吞吐量性能，下表中的基准测试数据示例清楚地阐释了这一点。
即使 Redis 服务器是单线程服务器，纵向扩展往往会提高吞吐量性能。 系统进程可以使用额外的 vCPU，而不是共享 Redis 进程正在使用的 vCPU。 纵向扩展在 Enterprise 和 Enterprise Flash 层上特别有用，因为 Redis Enterprise 并不局限于单个线程。
在 Premium 层上，通常建议在纵向扩展之前横向扩展（聚类分析）。 群集允许 Redis 服务器通过对数据进行分片来使用更多 vCPU。 在这种情况下，添加分片时，吞吐量应大致呈线性增长。
在 C0 和 C1 标准缓存上，当内部 Defender 扫描正在 VM 上运行时，服务器负载可能会出现短暂的峰值（不是由缓存请求数增加导致的）。 当每天在这些层级上多次运行内部 Defender 扫描时，请求延迟更高。 C0 和 C1 层上的缓存只有一个核心用来进行多任务处理，并将服务于内部 Defender 扫描和 Redis 请求的工作分开。 可以通过缩放到具有多个 CPU 核心的更高层级产品/服务（例如 C2）来降低影响。
更高层级上增加的缓存大小有助于解决任何延迟问题。 此外，在 C2 级别，可以支持多达 2,000 个客户端连接。
Redis 基准示例
测试前的设置：准备好缓存实例以及测试延迟和吞吐量所需的数据：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024
测试延迟：使用 1k 有效负载测试 GET 请求：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4
测试吞吐量：使用 1k 有效负载测试管道 GET 请求：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
若要使用 TLS 测试 Basic、Standard 或 Premium 层缓存的吞吐量：有效负载为 1k 的管道 GET 请求：
redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --tls
若要使用 OSS 群集模式测试没有 TLS 的 Enterprise 或 Enterprise Flash 缓存的吞吐量：有效负载为 1k 的管道 GET 请求：
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --cluster
性能基准数据示例
下表显示了在测试各种大小的 Standard、 Premium、 Enterprise 和 Enterprise Flash 缓存时观察到的最大吞吐量值。 我们针对 Azure Cache for Redis 终结点使用了来自 IaaS Azure VM 的 redis-benchmark 和 memtier-benchmark。 吞吐量数字仅适用于 GET 命令。 通常，SET 命令的吞吐量较低。 这些数字针对吞吐量进行了优化。 可接受的延迟条件下的实际吞吐量可能较低。
注意
这些值是没有保证的，并且不存在针对这些数字的 SLA。 我们强烈建议你执行自己的性能测试，以确定适合应用程序的缓存大小。 因为我们会定期发布更新结果，这些数字可能会更改。
重要
Microsoft 会定期更新缓存实例中使用的基础 VM。 这可以更改不同缓存之间和不同区域之间的性能特征。 本页上的示例基准测试值反映了单个区域中的旧一代缓存硬件。 在实践中，你可能会看到更好的或不同的结果。
以下配置用于对基本层、标准和高级层的吞吐量进行基准测试：
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
标准层 Redis 基准
| 实例 | 大小 | 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 |
高级层 Redis 基准
| 实例 | 大小 | 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 |
重要
中国东部和中国北部区域的 P5 实例使用 20 个核心而不是 32 个核心。
Enterprise 层和 Enterprise Flash 层
Enterprise 和 Enterprise Flash 层提供了群集策略选择：Enterprise 和 OSS。 Enterprise 群集策略是一种更简单的配置，不需要客户端支持聚类分析。 而 OSS 群集策略使用 Redis 群集协议来支持更高的吞吐量。 在大多数情况下，我们建议使用 OSS 群集策略。 有关详细信息，请参阅群集。 下表显示了这两个群集策略的基准。
以下配置用于对 Enterprise 层级和 Enterprise Flash 层级的吞吐量进行基准测试：
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32
注意
此配置与用于对基本层、标准层和高级层进行基准测试的配置几乎完全相同。 不过，以前的配置并没有充分利用 Enterprise 层级的更高计算性能。 为了演示完整性能，已经向此配置添加了额外的请求和线程。
Enterprise 群集策略
| 实例 | 大小 | vCPU | 预期的网络带宽 (Mbps) | 不带 SSL 的每秒 GET 请求数（1-kB 值大小） |
带 SSL 的每秒 GET 请求数（1-kB 值大小） |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4,000 | 300,000 | 207,000 |
| E20 | 25 GB | 4 | 4,000 | 680,000 | 480,000 |
| E50 | 50 GB | 8 | 8,000 | 1,200,000 | 900,000 |
| E100 | 100 GB | 16 | 10,000 | 1,700,000 | 1,650,000 |
| F300 | 384 GB | 8 | 3,200 | 500,000 | 390,000 |
| F700 | 715 GB | 16 | 6,400 | 500,000 | 370,000 |
| F1500 | 1455 GB | 32 | 12,800 | 530,000 | 390,000 |
OSS 群集策略
| 实例 | 大小 | vCPU | 预期的网络带宽 (Mbps) | 不带 SSL 的每秒 GET 请求数（1-kB 值大小） |
带 SSL 的每秒 GET 请求数（1-kB 值大小） |
|---|---|---|---|---|---|
| E10 | 12 GB | 4 | 4,000 | 1,400,000 | 1,000,000 |
| E20 | 25 GB | 4 | 4,000 | 1,200,000 | 900,000 |
| E50 | 50 GB | 8 | 8,000 | 2,300,000 | 1,700,000 |
| E100 | 100 GB | 16 | 10,000 | 3,000,000 | 2,500,000 |
| F300 | 384 GB | 8 | 3,200 | 1,500,000 | 1,200,000 |
| F700 | 715 GB | 16 | 6,400 | 1,600,000 | 1,200,000 |
| F1500 | 1455 GB | 32 | 12,800 | 1,600,000 | 1,110,000 |
Enterprise 层和 Enterprise Flash 层 – 已横向扩展
除了通过移动到更大的缓存大小进行纵向扩展外，还可以通过横向扩展来提高性能。在 Enterprise 层中，横向扩展被称为增加缓存实例的容量。 默认情况下，缓存实例的容量为 2，即主节点和副本节点。 容量为 4 的 Enterprise 缓存实例表示该实例已横向扩展 2 个单位。 横向扩展可提供对更多内存和 vCPU 的访问。 有关核心 Redis 进程在每个缓存大小和容量上使用多少个 vCPU 的详细信息，请参阅分片配置。 使用 OSS 群集策略时，横向扩展最为有效。
下表显示了不同容量（使用 SSL 和 1-kB 值大小）的每秒 GET 请求数。
横向扩展 - Enterprise 群集策略
| 实例 | 容量 2 | 容量 4 | 容量 6 |
|---|---|---|---|
| E10 | 200,000 | 830,000 | 930,000 |
| E20 | 480,000 | 710,000 | 950,000 |
| E50 | 900,000 | 1,110,000 | 1,200,000 |
| E100 | 1,600,000 | 1,120,000 | 1,200,000 |
| 实例 | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
横向扩展 - OSS 群集策略
| 实例 | 容量 2 | 容量 4 | 容量 6 |
|---|---|---|---|
| E10 | 1,000,000 | 1,900,000 | 2,500,000 |
| E20 | 900,000 | 1,700,000 | 2,300,000 |
| E50 | 1,700,000 | 3,000,000 | 3,900,000 |
| E100 | 2,500,000 | 4,400,000 | 4,900,000 |
| 实例 | 容量 3 | 容量 9 |
|---|---|---|
| F300 | 1,200,000 | 2,600,000 |
| F700 | 1,200,000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |