使用 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. 从虚拟机的 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 示例

测试前的设置：使用测试所需的数据准备缓存实例。 使用数据加载实例可确保结果更准确地反映实际情况。 {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

测试吞吐量：此命令使用 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 实例时观察到的最佳吞吐量，其中包含所有读取命令和 1KB 有效负载的工作负荷。 除连接计数（即memtier_benchmark所需的不同线程和客户端计数）外，所有 SKU 的工作负荷相同。 为每个 SKU 选择连接计数，从而以最佳方式利用 Azure Managed Redis 实例。 我们使用了 IaaS Azure VM 提供的针对 Azure 托管的 Redis 终结点的 memtier_benchmark，利用 memtier_benchmark 示例部分显示的 memtier 命令。 吞吐量数字仅适用于 GET 命令。 通常，SET 命令的吞吐量较低。 实际性能因 Redis 配置和命令而异。 这些数字仅作参考，不是保证。

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

下表列出了基于 memtier_benchmark 线程计数和客户端计数的连接计数，该数据用于生成吞吐量数值。 如上所述，更改连接计数可能会导致不同的性能。

后续步骤

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