介绍 Redis/Intel 用于性能测试、分析和调优的基准规范

Redis 和 Intel 正在合作开发一种“零接触”的性能和分析自动化方案，以扩展 Redis 发现性能退步和提高数据库代码效率的能力。Redis 基准规范描述了跨语言和工具的要求及预期，旨在围绕 Redis 相关技术建立性能和可观察性标准。

Redis 作为键值数据库之所以受欢迎，一个主要原因是其性能，其查询响应时间以亚毫秒计。为了持续改进 Redis 组件的性能，Redis 和 Intel 合作开发了一个框架，可在代码提交时自动触发性能测试、遥测数据收集、分析和数据可视化。目标很简单：尽早发现性能变化。

该自动化方案为 Intel 等硬件合作伙伴提供了关于软件如何使用平台的洞察，并发现了在 Intel CPU 上进一步优化 Redis 的机会。最重要的是，对软件更深入的理解有助于 Intel 设计出更好的产品。

在这篇博文中，我们将介绍 Redis 和 Intel 如何在这种自动化方面进行合作。“零接触”分析可以扩展对性能退步的追踪，并寻找提高数据库代码效率的机会。

标准规范：动机与要求

Redis 和 Intel 都希望发现软件和硬件的优化机会。为了实现这一目标，我们决定围绕性能和可观察性相关的要求和预期，建立一套跨公司和跨社区的标准。

从软件角度来看，我们的目标是自动识别性能退步，并深入了解热点，从而找到改进机会。我们希望该框架易于安装，测试用例覆盖全面，并且易于扩展。目标是适应定制基准测试、基准测试工具以及跟踪/探测机制。

从硬件角度来看，我们希望比较不同代别的平台，以评估新硬件功能的影响。此外，我们希望收集遥测数据并执行“假设”测试，例如频率扩展、核心扩展以及缓存预取器开启与关闭测试。这有助于我们隔离这些优化对 Redis 性能的影响，并为不同的优化以及未来的 CPU 和平台架构决策提供信息。

标准规范实现

基于上述前提，我们创建了Redis 基准规范框架。它可以通过 PyPi 轻松安装，并提供了简单的方法来评估 Redis 的性能以及运行 Redis 的底层系统。Redis 基准规范目前包含近 60 个不同的基准测试，涉及多种命令和功能。您可以轻松地使用自己的定制基准测试、基准测试工具以及跟踪或探测机制对其进行扩展。

Redis 和 Intel 持续运行该框架的基准测试。我们按分支和标签分解每个基准测试结果，并解释随时间和版本变化的性能数据。此外，我们使用该工具批准与性能相关的 Redis 项目拉取请求。决策过程包括基准测试结果以及结果原因的解释，这些解释是通过在“零接触”全自动模式下使用分析工具和探测器输出获得的。

结果是：我们可以生成平台层面的洞察，并执行“假设”分析。这得益于用于收集硬件相关遥测数据的开源跟踪和探测工具，例如 memtier_benchmark、redis-benchmark、Linux perf_events、bcc/BPF 跟踪工具、Brendan Greg 的火焰图仓库以及Intel Performance Counter Monitor。

如果您对我们如何将分析器与 Redis 结合使用感兴趣，请参阅我们极其详细的CPU 上分析和跟踪的性能工程指南。

那么，它是如何工作的呢？很高兴您提问了。

软件架构

Redis 基准规范的一个主要目标是尽早发现性能变化。这意味着一旦我们将一组更改推送到 Git，就可以（或者应该）立即评估这些更改在多个基准测试中衡量的性能影响。

一个积极的影响是核心 Redis 维护者工作更轻松了。只需使用 ‘action run:benchmarks‘ 标签标记特定的拉取请求 (PR)，即可触发 CI/CD 基准测试。然后，该触发器会转换为一个事件（在 Redis 内部跟踪），根据 Redis 基准规范平台参考中描述的不同平台启动多个构建变体请求。

当收到新的构建变体请求时，构建代理（redis-benchmarks-spec-builder）准备工件。它添加一个工件基准测试事件，以便所有基准测试平台（包括 Intel Lab 上的平台）都能监听基准测试运行事件。这还启动了部署和管理所需基础设施和数据库拓扑、运行基准测试以及导出性能结果的过程。所有数据都存储在 Redis 中（使用 Redis Stack 功能）。这些数据随后用于基线构建和对比构建之间的方差分析（如下图所示），以及同一分支/标签上随时间变化的方差分析。

对同一工作分支的新提交会产生一组新的基准测试事件，并重复上述过程。

example diagram for a workflow with PR triggered benchmark run — 图 1. 平台架构，从触发拉取请求工作流阶段到多个基准测试代理生成最终基准测试和分析数据。

Intel 实验室硬件配置

该框架可以部署在本地，也可以部署在云端。在我们的合作中，Intel 托管了一个本地服务器集群，专用于始终运行的自动性能测试框架（参见图 2）。

intel lab cloud benchmark diagram — 图 2. Intel 实验室设置

该集群包含六台当前一代（IceLake）服务器和六台上一代（CascadeLake）服务器，连接到高速 40Gb 交换机（参见图 3）。旧的服务器用于跨硬件代际的性能测试，以及客户端-服务器基准测试中的负载生成客户端。

我们计划扩展实验室，纳入多代服务器，包括用于早期评估和拟议平台功能的“假设”分析的 BETA（预发布）平台。

专用本地设置的一个明显优势是，我们可以获得更稳定的结果，运行之间的差异更小。此外，我们可以灵活地修改服务器，根据需要添加或移除组件。

展望未来

如今，Redis 基准规范是 Redis 中性能团队使用的实际性能测试工具集。它在日常持续集成 (CI) 中运行近 60 个基准测试，我们也用它来进行手动性能调查。

我们已经看到了好处。在 Redis 7.0 和 7.2 的开发周期中，新规范已经使我们能够准备全新的改进，例如这些拉取请求中的改进

将编译器优化更改为 -O3 -flto。在基准 SPEC 测试中测得性能提升高达 5%。
在 addReplyDouble 中一次性使用 snprintf 。简单的 ZADD 性能提升约 25%。
将客户端标志移动到客户端结构中更利于缓存的位置。恢复了自 v6.2 以来损失的 2% 的 CPU 周期。
使用grisu2优化 d2string() 和 addReplyDouble()。如果我们查看 ZRANGE WITHSCORES 命令的影响，我们发现在回复 10 个元素时，每秒可实现的操作数提高了 23%，在回复 100 个元素时提高了 50%，在回复 1,000 个元素时提高了 68%。
优化 XADD key * 命令中的 stream id sds 创建。结果：节省了约 20% 的 CPU 周期。
使用单调时钟或墙钟来测量命令执行时间。恢复了高达 4% 的执行时间。
在 ZRANGE BYRANK 命令中避免延迟数组回复。恢复了自 v5 以来因新增功能而损失的 3% 到 15% 的性能。
优化延迟回复，使用共享对象而不是 sprintf。在 ZRANGE 命令中测得性能提升 3% 到 9%。

总而言之，上述工作使相关命令的性能提升高达 68%。

intel benchmarks — 图 4. Redis 开发者组 Grafana 跟踪每个平台/基准测试/版本性能随时间变化的示例可视化。

未来工作

我们目前的性能工程系统使我们能够在开发周期中检测性能变化，并使我们的开发者能够理解其代码更改的影响。虽然我们已经取得了显著进展，但仍有许多方面我们希望

改进。

我们正在努力提高跨一组基准测试汇总性能数据的能力。这将使我们能够回答诸如“在所有基准测试中，哪些是 CPU 消耗最高的堆栈？”以及“在所有命令中，哪些是优化并产生最大影响的最容易实现的目标？”之类的问题。

此外，我们的基线与比较分析在很大程度上依赖于简单的基于方差的计算。我们打算采用更好的统计分析方法，以便对多个数据点进行基于趋势的分析，并进行更细粒度的分析，以避免云环境中嘈杂的“温水煮青蛙问题”。

Redis API 有超过 400 个命令。我们需要不断努力提高整个 API 性能的可见性和改进性能。同时，我们还需要根据社区和客户反馈，重点关注最常用的命令。

我们希望扩展部署选项，包括集群级基准测试、复制等。我们计划丰富可视化和分析功能，并计划将测试扩展到更多硬件平台，包括 Intel 的早期（预发布）平台。

我们的目标是在社区和 Redis 开发者组中推广我们的性能平台，使其得到更广泛的使用。我们在此项目中获得的数据和不同视角越多，就越有可能提供更快的Redis。