通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure 托管 Redis（预览版）进行性能测试

  • 项目

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

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

如何使用 memtier_benchmark 实用工具

  1. 在可用于测试的客户端虚拟机 (VM) 上安装 memtier。 有关如何安装开源映像的说明，请参阅 Memtier 文档。

  2. 用于测试的客户端虚拟机 (VM) 应与 Azure 托管 Redis (AMR) 实例位于同一区域。

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

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

  5. 如果在缓存实例上使用 TLS/SSL，需要将 --tls 和 --tls-skip-verify 参数添加到 memtier_benchmark 命令。

  6. 默认情况下，memtier_benchmark 使用端口 6379。 使用 -p 10000 参数替代此设置，因为 AMR 转而使用端口 10000。

  7. 对于所有使用 OSS 群集策略的 Azure 托管 Redis 实例，需要将 --cluster-mode 参数添加到 memtier 命令。 使用 Enterprise 群集策略的 AMR 实例可以被视为非聚集缓存，不需要此设置。

  8. 从 VM 的 CLI 或 shell 启动 memtier_benchmark。 有关如何配置和运行该工具的说明，请参阅 Memtier 文档。

基准测试建议

  • 如果未获得所需的性能，请尝试纵向扩展到更高级的层级。 均衡层的 vCPU 数量通常是内存优化层的两倍，而计算优化层通常的 vCPU 数量通常是均衡层的两倍。 由于 Azure 托管 Redis 是基于 Redis Enterprise 而不是社区版 Redis 构建的，因此核心 Redis 进程能够利用多个 vCPU。 因此，具有更多 vCPU 的实例的吞吐量性能显著提高。

  • 纵向扩展到更大的内存大小还会增加更多的 vCPU，从而提高性能。 但是，纵向扩展到更大的内存大小通常比使用性能更高的层级效果更低。 有关每个大小和层级可用的 vCPU 的详细细分，请参阅层级和 SKU 概述。

  • 闪存优化层的基准测试可能很困难，因为有些键存储在 DRAM 上，而有些键存储在 NVMe 闪存磁盘上。 DRAM 基准上的键几乎与其他 Azure 托管 Redis 实例一样快，但 NVMe 闪存磁盘上的键速度要慢一些。 由于闪存优化层会智能地将最常用的键放入 DRAM，请确保基准配置符合预期的实际使用情况。

  • 使用 TLS/SSL 会降低吞吐量性能，但强烈建议将其作为生产最佳做法。

  • 在基准测试之前，使用数据填充 Redis 实例至关重要。 在空缓存上进行基准测试产生的结果比实际看到的结果要好得多。

  • 使用的连接数量对基准具有显著影响。 使用过多的连接会开始降低缓存的性能。 使用太少的连接又并不能发挥缓存的全部性能。 建议根据实际应用程序需求来配置连接数量。 通过将客户端数量乘以线程数量来确定连接总数。

  • 管道配置对性能测试有显著影响。 如果将管道设置设置为更大，会看到更多的吞吐量，但延迟更差。 有关详细信息，请参阅管道。

memtier_benchmark 示例

注意

此示例显示使用 OSS 群集策略和 TLS 在计算优化 X3 实例上进行基准测试的情况。

测试前的设置：使用测试所需的数据准备缓存实例。 使用数据加载实例可确保结果更准确地反映实际情况。 {number-of-keys} 参数应由 AMR 实例的大小和每个键的大小来确定。 一个很好的经验法是将实例填满大约 75%，其中包括缓冲区。 你可以使用此公式：numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300)。 例如，如果要对计算优化 X3 实例进行基准测试，则使用 1,024 字节的键大小，如前所示，这意味着 {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)。 会得到大约 1,699,396 个键。

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

注意

此示例使用 --tls、--tls-skip-verify 和 --cluster-mode 标志。 如果在非 TLS 模式下使用 Azure 托管 Redis，或者使用 Enterprise 群集策略，则不需要这些项。

测试吞吐量：此命令使用 1k 有效负载测试管道 GET 请求。 使用此命令测试预计从缓存实例获得多少读取吞吐量。 此示例假定你使用的是 TLS 和 OSS 群集策略。 --key-pattern=R:R 参数可确保随机访问键，从而提高基准的真实性。 此测试运行 5 分钟。

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

性能基准数据示例

下表显示了在测试各种大小的 Azure 托管 Redis 实例时观察到的最大吞吐量值。 我们针对 Azure 托管 Redis 终结点使用 IaaS Azure VM 中的 memtier_benchmark，并使用 memtier_benchmark 示例部分中所示的 memtier 命令。 吞吐量数字仅适用于 GET 命令。 通常，SET 命令的吞吐量较低。 实际性能因 Redis 配置和命令而异。 这些数字仅作参考，不是保证。

注意

这些值是没有保证的，并且不存在针对这些数字的 SLA。 我们强烈建议你执行自己的性能测试，以确定适合应用程序的缓存大小。 因为我们会定期发布更新结果，这些数字可能会更改。

重要

Microsoft 会定期更新缓存实例中使用的基础 VM。 这可以更改不同缓存之间和不同区域之间的性能特征。 本页上的示例基准测试值反映了单个区域中的旧一代缓存硬件。 在实践中，你可能会看到更好的或不同的结果，特别是使用网络带宽时。

Azure 托管 Redis 提供群集策略的选择：Enterprise 和 OSS。 Enterprise 群集策略是一种更简单的配置，不需要客户端支持聚类分析。 另一方面，OSS 群集策略使用 Redis 群集协议来支持更高的吞吐量。 在大多数情况下，我们建议使用 OSS 群集策略。 有关详细信息，请参阅群集。

下表显示了这两个群集策略的基准。 对于 OSS 群集策略表，提供了两个基准测试配置：

  • 300 个连接（50 个客户端和 6 个线程）
  • 2,500 个连接（50 个客户端和 50 个线程）

提供了第二个基准，因为 300 个连接不足以充分演示较大缓存实例的性能。

以下是 AMR 实例在每秒 GET 操作（针对 1 kB 有效负载）上的吞吐量，以及用于基准测试的客户端连接数量。 所有数字都是针对使用 SSL 连接的 AMR 实例计算的，并且网络带宽以 Mbps 为单位记录。

OSS 群集策略

大小 (GB) vCPU/网络 BW/内存优化 vCPU/网络 BW/均衡 vCPU/网络 BW/计算优化
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

Enterprise 群集策略

大小 (GB) vCPU/网络 BW/内存优化 vCPU/网络 BW/均衡 vCPU/网络 BW/计算优化
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200