对比评测使用 Redis 的全新 AWS M3 实例

两周前，亚马逊推出了其下一代标准实例（M3 实例），在提供与 M1 实例相同的平衡 CPU 和内存资源的同时，计算能力/核心数量翻了一番。我们不在我们的 Redis Cloud 集群中使用 M1 实例（它们无法应对 Redis 对高吞吐量、低延迟的要求，详情请见此处），但我们想知道 M3 双倍超大实例 (m3.2xlarge) 是否真的比我们在许多集群节点中使用的 m2.2xlarge 高内存实例表现更好。这两个实例具有相似的内存配置并使用相同类型的 vcores，因此最令我们好奇的是 M3 实例可以在 Xen 硬件虚拟化模式 (HVM) 下运行。因此，它们应该能克服严重影响 Redis 性能的 Xen fork time 问题（详情请见此处）。此外，m3.2xlarge 实例的 vcore 数量是 m2.2xlarge 实例的两倍，而额外成本不到 30%。

测试场景 考虑到以上所有因素，我们对 Redis 在 m3.2xlarge 和 m2.2xlarge 实例上的性能进行了以下比较测试

• Fork 时间
• 纯内存配置的吞吐量和延迟
• 启用 AOF 并在正常条件下（禁用 AOF 重写）的吞吐量和延迟
• 复制时间

测试复制时间很重要，因为 m3.2xlarge 不带临时存储，或者更准确地说，只有 15GB 的本地磁盘大小。这意味着即使不需要数据持久性，也必须连接到一个 EBS 卷，因为 Redis 复制过程需要在持久性存储上两次写入整个数据集（主节点和从节点）。由于 EBS 在顺序写入方面速度较慢（更多详情请见此处），我们想看看 Redis 复制是否以及如何受此配置影响。 事不宜迟，以下是我们的发现：Fork 时间

正如预期，使用 m3.2xlarge 实例的 fork 时间明显低于 m2.2xlarge 实例上的 fork 时间，因为它使用了 Xen 的完全虚拟化模式 (HVM)。在 AWS Cluster Compute 实例上也看到了类似的低 fork 时间结果（更多信息请见此处），但实例成本要高得多。 吞吐量和延迟 我们比较了单个分片 Redis 在这两个实例上的吞吐量和延迟，结果如下

我们的洞察

• 在每次测试中，m2.2xlarge 的吞吐量高约 15%，延迟低约 12%。这是我们预期的结果，因为考虑到所需的模拟，完全虚拟化的客户机 (HVM) 通常比半虚拟化的客户机慢。
• 当我们在带有半虚拟化 AMI 的 m3.2xlarge 实例上运行 Redis 时，我们看到了相同的单个分片 Redis 性能，但在 fork 时间方面没有改进。
• 在具有多个 Redis 进程的环境中（即多个专用 Redis DB 或多分片 Redis），当活动进程的数量超过 m2.2xlarge 实例的 4 个 vcores 时，我们预计 m3.2xlarge 将表现更好

复制时间

为了测量复制时间，我们在从节点连接到主节点时开始测量，并在从节点同步完成时停止。虽然我们将 m2.2xlarge 实例配置为使用运行速度高达 80 MB/秒（峰值）的本地磁盘接口，并将 m3.2xlarge 配置为使用运行速度高达 30 MB/秒（峰值）的 EBS 接口，但 m2.2xlarge 实例的总复制时间仅快了 13%。我们认为这是因为在这种 RDB 文件大小下，填充过程占用了大部分时间。我们假设填充时间与整个复制过程的时间之比与 RDB 文件的大小呈线性关系。因此，文件越大，磁盘访问吞吐量对整个复制过程的影响就越小。小型 RDB 文件的复制本质上是快速的，因此可以肯定地说，更高吞吐量的存储接口不会显著影响整个复制过程。 结论 AWS 带有 HVM AMI 的新 M3 实例完全消除了 Xen fork time 问题，该问题在进行时间点快照或重写 Append Only Files (AOF) 后台保存过程时严重影响了 Redis 性能。另一方面，单线程 Redis 服务器在 m3.2xlarge 实例上的性能在纯内存和 AOF 测试中都比 m2.2xlarge 实例慢约 15%。m2.3xlarge 实例的复制时间也较慢，但没有我们预期的那么显著。我们的建议是，仅在您运行不带复制的 Redis 或需要在同一实例上运行四个以上 Redis 进程时，才使用 m3.2xlarge 而非 m2.2xlarge。对于所有其他情况，我们仍然推荐使用 m2.2xlarge 实例。 测试设置 对于想了解更多测试详情的人，以下是我们使用的资源

• 以下配置的 Redis Cloud
  • 2 个 m3.2xlarge 实例
  • 2 个 m2.2xlarge 实例
• 在这两种配置中，我们都使用了标准 EBS 卷：100GB（非 RAID）

这是我们的负载生成设置：一个 m2.2xlarge 实例，运行我们开发的 memtier_benchmark 负载生成工具（一个高级负载生成工具，我们很快将在我们的 github 帐户中分享）。 为了测试 fork 时间，我们采取了以下步骤

• 我们使用不同数据类型的各种对象填充内存
• 我们启用了 AOF 并等待第一次重写操作完成
• 我们使用 memtier_benchmark 在随机键上生成高负载，以访问尽可能多的内存页
• 我们执行了 GBREWRITEAOF
• 我们读取了 Redis INFO 的 latest_fork_usec 值

为了测试吞吐量和延迟，我们进行了 2 次测试

• 禁用数据持久性
• 使用 AOF 并设置为“每秒 fsync”

我们在每种配置上运行了三次测试，并使用以下参数计算了平均结果

• 100 个连接
• 随机对象大小 100B-1000B
• GET/SET 比例 1:1

为了测试复制，我们

• 禁用了数据持久性
• 使用不同数据类型的各种对象填充内存
• 断开了从服务器
• 在从节点重新连接到主节点时开始测量
• 在从节点同步完成时停止测量
• 同时，我们继续在主服务器上生成应用负载