P99 CONF 是一个专注于性能的免费虚拟会议。每年，来自世界各地的数千名痴迷于延迟的工程师都会参加P99 CONF。它是纯技术性的、有意虚拟的、高度互动的并且注重开源。

Rust 和低延迟系统的未来 - Bryan Cantrill

没有任何评论可以公正地评价Bryan Cantrill（Oxide Computer 公司的联合创始人兼首席技术官）信息丰富且充满激情的主题演讲。

在短短20 分钟内，他带领观众回顾了迄今为止的计算历史，对我们今天的处境提出了严厉的批评，并展望了该行业未来的发展方向。我们在“Bryan Cantrill on Rust and the Future of Low-Latency Systems”中以文章形式介绍了它，但请相信我们- 您需要观看此视频。

以下是预览：坎特里尔用自己的话给出了他的结论：

“Rust 实际上是自C 以来第一种真正存在于硬件和软件边界的语言。这就是为什么它引导我们走向未来。

“赖特定律意味着我们将在更多地方拥有更多计算能力。我们已经看到了这一点。这些计算元素将变得专业化。不要指望您的通用CPU 会被塞进SmartNIC 中。它是我们不能有那么快的内存。

“但是我们可以把Rust 放在那里。Rust 可以适应这些地方。我们将看到更多令人兴奋的新的面向硬件的Rust 系统- 感谢no_std - 将能够相互构建。

“这是开发高性能、低延迟系统的激动人心的时刻，Rust 革命就在这里。”

哎呀！我用 Rust 重写了它 - Brian Martin

Twitter（现在的X）服务的可扩展性和效率在很大程度上依赖于高质量的缓存产品。该团队在那里开发了Pelikan 作为缓存系统，因为Memcached 和Redis 并不能完全满足他们的需求。百利金的首要任务是“通过面向延迟的设计和简化的实施来实现一流的效率和可预测性”。最初，这是通过C 实现来实现的。然而，随后的两个项目将Rust 引入到框架中，并取得了相当惊人的开发速度。

当他们决定向Pelikan 添加TLS 支持时，Twitter 软件工程师Brian Martin 怀疑用Rust 完成这项工作会比用C 更快、更高效。但为了获得批准，Rust 实现必须匹配（或超过） C 实现的性能。

从性能角度来看，使用现有基于Rust 的Twemcache 的初始原型并不乐观；它们导致P999 延迟增加25% 到50%，吞吐量减少10% 到15%。即使Martin 加倍努力优化Rust 原型的性能，他也看到了微不足道的结果。在经历了更令人沮丧的性能测试结果后，他考虑了几种不同的实现方法。幸运的是，当他权衡潜在的权衡时，他发现了一种新的存储设计，可以更轻松地将整个存储库移植到Rust。

当时，Martin 全力投入Rust，使用简化的单线程应用程序，所有内存分配均由Rust 管理。结果如何？ 100% Rust 实现不仅提供了与C 实现和memcached 相匹配或超过的性能：它还改进了整体设计，并通过“出色的语言功能和工具”使编码更加自信，Martin 随后深入研究了这些功能和工具。

保持低延迟和高吞吐量 - Avi Kivity

吞吐量和延迟始终处于压力之下。 ScyllaDB 的CTO 兼联合创始人Avi Kivity 在主题演讲中重点介绍了如何通过应用程序级优先级调度在单个应用程序中实现高吞吐量和低延迟。

Kivity 首先概述了吞吐量计算(OLAP) 和延迟计算(OLTP) 之间的鲜明对比，并解释了在单个应用程序中混合这两种类型作业的有意义的场景。当需要混合时，两个核心操作至关重要：

隔离延迟和吞吐量作业的不同任务，以便您可以测量和控制它们。以一种允许延迟作业快速完成且不受吞吐量作业干扰的方式安排延迟作业。但问题在于细节。您是否遵循在线程中隔离任务并让内核调度它们的常见方法？这通常更容易，但它不能提供足够的控制或效率来实现最佳结果。

另一种选择是应用程序级任务隔离。这里，每个操作都是一个普通对象，任务在少量线程上复用（理想情况下，每个逻辑核心一个线程，在同一线程上同时具有吞吐量敏感的任务和延迟敏感的任务）。并发框架将任务分配给线程并控制任务的执行顺序。这意味着您可以根据自己的喜好微调所有内容，但所有这些微调可能会让人上瘾，并分散您对其他关键任务的注意力。更多优点：低开销、更简单的锁定、良好的CPU 亲和性和更少的内核意外。这是一个不太成熟（但正在改进）的生态系统，但Kivity 坚信，额外的努力将会获得巨大的回报。

在可视化执行时间线后，Kivity 详细介绍了切换队列、抢占技术和使用停顿检测器。最后，他解释了这一切在现实示例中的工作原理：ScyllaDB 数据库。

痛苦指标和后果 - Gil Tene

Gil Tene 传奇般的“oh sh*t”谈话促使许多工程师重新考虑测量P99 和类似延迟的方法。但十多年来，吉尔一直致力于如何改进性能测量并了解分布式系统的演变，他自己的解决该主题的方法已经发生了演变。

从《奇爱博士》到《黑客帝国》，再到献祭山羊，Azul Systems 联合创始人兼首席技术官Tene 带领观众经历了从高延迟高峰到绝望低谷的旅程。他用“所有漂亮的图表”解构了我们真正看到的东西，更重要的是，解构了我们所缺少的东西。这次演讲会让您想知道您在我们的活动徽标—— 中看到的图表背后到底发生了什么，并且可能会让您对P99 本身的概念进行很多思考。在看似绝望的低谷中，Tene 展示了一个相当可怕的例子，说明提高图表性能的操作可能会严重损害最终用户体验。多么痛苦啊。

但特内仍然相信，实际上有可能克服我们公认的绩效衡量方法的缺点，只是不像他最初想象的那样。痛苦中也有希望。隧道尽头有光。甚至还有彩虹（也许是因为Tene 从夏威夷加入我们）。事实证明，工程师可以通过学会热爱疼痛来预防疼痛。如果你还不明白，现在是时候服用红色药丸并观看他的演讲了。

从 SLO 到“年度游戏” - Charity Majors

慈善专业以其敏锐的洞察力而闻名。 —— 她关于服务水平目标(SLO) 的P99 CONF 主题演讲也不例外。对延迟敏感的工程师可以从游戏中学到很多东西，在游戏中，任何不完美的体验都可能会破坏即使是最具想象力的设计。这就是工具和遥测技术发挥作用的地方。正如梅杰斯所说，“不出现问题是不可能的。但在用户注意到之前发现并解决问题是可能的。你真的希望用户认为这是理所当然的。”

但你如何衡量这种体验呢？在Tene 首次介绍并由Alex Hidalgo 和Brian Taylor 讨论过的丑陋的P99 现实之后，Majors 宣称，“聚合是胡说八道。每个人的经验都很重要。任何可以登录的玩家都可以在论坛上发帖”你的系统可能有四个九，但仍然……

今天登录的每个人都可能会将自己的状态保存到一个无响应的分片中，并认为您完全崩溃了。在某些地区，每个人都可能会出现登录延迟的情况。注册时付款更新可能会失败。有效的可观察性是工程经验和用户体验之间隐藏的联系。根据梅杰斯的说法，“如果没有可观察性，你基本上就是蒙着眼睛开车。你在不戴眼镜的情况下在高速公路上超速行驶。”可观察性应该帮助您了解幕后情况。—— 让您能够调试代码、重新创建任何用户体验，甚至无需发布新代码即可了解新场景。它应该可以帮助您超越“这是坏了吗？”的问题。到“它是如何工作的以及我的用户正在体验什么？”你做得越好，遇到的故障就越少。

但如何在游戏或其他复杂、高度分布式的系统中实现这种独角兽般的可观察性水平呢？这些系统：

跨多个云、数据中心和区域部署由世界各地的众多团队设计和开发用于数千种设备类型容易出现巨大的并发问题和“惊群”

使用 eBPF 进行高性能网络 - Liz Rice

Cisco Isovalent 首席开源官Liz Rice 告诉与会者Cilium（云原生计算基金会的一部分）如何通过使用eBPF 绕过部分网络堆栈来提高吞吐量、释放CPU 使用率并提高Kubernetes 网络的效率。

使用XDP（快速数据路径），Cilium 可以在网络接口卡上运行eBPF 程序，使您可以在网络数据包到达时立即利用eBPF。例如，正如Rice 所示，您可以使用eBPF 作为一种非常快速且有效的方法来识别和丢弃“死包”。值得注意的是，这种缓解措施可以动态加载，无需安装内核补丁或重新启动计算机。这只是如何使用eBPF 动态更改系统中的网络行为的示例之一。

eBPF 还可用于操纵数据包—— 例如，更改数据包中包含的源地址和目标地址以实现负载平衡。当数据包到达时，eBPF XDP 程序可以确定将其发送到该主机上的何处（第——章）或发送到另一台机器（第——章），而无需内核的网络堆栈处理该数据包。这使得性能得到显着提高。 （示例A：了解Seznam.cz 如何通过将基于XDP 的负载均衡器与IPVS 负载均衡器一起运行来实现两倍以上的吞吐量并节省“令人难以置信的CPU 使用率”。）

除了XDP之外，eBPF程序还可以附加到网络堆栈中的各个不同点，这在处理Kubernetes复杂的网络堆栈时特别有用。正如Rice 的演示、火焰图和基准测试所示，这为吞吐量和CPU 改进提供了更多机会。观看视频以直接了解性能影响。

极端 HTTP 性能调优 - Marc Richards

Marc Richards 拥有十多年调优高级性能的经验，最近致力于一个用C 语言编写的API 服务器的低级系统性能调优项目。回顾这次冒险，他的演讲首先提出了三个建议，这些建议适用于任何有兴趣开始进行低级性能调整的人：

您不需要成为内核开发人员或向导系统管理员；它需要好奇心和毅力，但你绝对可以通过实践来学习。 FlameGraph 和bpftrace 改变了游戏规则，使这项工作变得更加容易。未来将会出现许多新的基于eBPF 的工具，这将使事情变得更容易。谈到调优的具体细节，Richards 概述了该系统的九个优化类别，该系统从一开始就表现良好（每秒224k 请求时的P999 为1.32 毫秒）。

理查兹继续解释了他应用的各种其他优化，详细说明了他决定进行每项更改的原因以及它带来的性能改进。该视频涵盖了从完美局部性和中断优化到“爱管闲事的邻居情况”的各种优化。如需了解Richards 在20 分钟演讲中提供的更深入的内容，请参阅他的博客“极端HTTP 性能调优：在4 个vCPU EC2 实例上实现1.2M API 请求/秒”。