让速度更快！方法性地提升 Redis 性能

Redis 在开发中非常注重性能。我们在每次发布中尽力确保您能体验到稳定且快速的產品。

但是，如果您发现可以提升 Redis 效率的空间，或者正在进行性能回归调查，那么您需要一种简明且系统的方法来监控和分析 Redis 的性能。这就是其中一项优化的故事。

最终，我们将流的导入性能提升了约 20%，您现在可以在Redis v7.0中体验到这一提升。

标准 SPEC

在深入优化之前，我们想让您大致了解我们是如何实现这一目标的。

如前所述，我们想要识别 Redis 性能回归和/或潜在的 CPU 性能提升。为此，我们认为需要在与性能和可观察性需求和期望相关的所有事项上，建立一套跨公司和跨社区的标准。

简而言之，我们不断运行 SPEC 的基准测试，将其细分为分支/标签，并以“零接触”全自动模式解读生成的性能数据，其中包括分析工具/探测器输出和客户端输出。

使用的工具都是开源的，依赖于诸如 memtier_benchmark、redis-benchmark、Linux perf_events、bcc/BPF 跟踪工具和 Brendan Greg 的FlameGraph 仓库等工具/流行框架。

如果您想详细了解我们如何使用分析器与 Redis，我们建议您查看我们的详细“针对 CPU 分析和跟踪的性能工程指南。”

完成第一步后，我们开始解读分析工具/探测器的输出。其中一个展现出有趣模式的基准测试是流的导入基准测试，它只是将数据导入流，使用的命令类似于以下命令：

`XADD key * field value`。

我们观察到，在没有 ID 的情况下向流添加数据时，它会在 SDS 创建/释放/sdslen 上产生重复工作，消耗了约 10% 的 CPU 周期，下一对 perf 报告打印中将详细展示这一点。

对于相同的输入，sdscatfmt 和 _sdsnewlen 被调用了两次

这使我们能够将流导入优化约 9-10%，这一点已在基准测试结果中得到证实

不稳定分支的基线 (6b403f5) :

此 PR 的首次提交（避免重复工作）

此用例改进的初始重点导致了 Oran（核心团队成员之一）的进一步分析，他注意到在相同的代码块内存在另一种浪费 CPU 周期的现象。这一次，这是由于代码块内的内存管理不佳。我们分配了一个空的 SDS，然后重新分配它。减少调用次数将为我们带来另一个速度提升，如下所示。

第二次提交（避免重新分配）

正如预期的那样，通过简单地重复使用中间计算，从而减少内部调用的函数中的冗余计算和分配，我们测得的Redis 流整体 CPU 时间减少了约 20%。

我们认为，这是一个表明即使对于像 Redis 这样已经深度优化的代码，系统性的简单改进也能带来显著的性能提升的例子。

我们的目标是扩展对 Redis 的性能可见性，鼓励行业和学术界成员（包括组织和个人）做出贡献。如果我们没有衡量它，我们就无法改进它。