如果 P99 延迟不准确,那用什么?

如果 P99 延迟不准确,那用什么?

那么 P99 存在什么问题?如果它们确实不准确,我们应该考虑什么替代指标呢?

翻译自 If P99 Latency Is BS, What’s the Alternative?

批评一个会议名称的核心概念通常是不被社会接受的。但 P99 CONF 并不是一次普通的会议。在 P99 CONF 22 上,社区和主办方都非常喜欢三位大胆的演讲者公开挑战 P99 延迟的价值。

P99 的质疑始于 Azul 公司的 CTO Gil Tene ,他以如何“不要测量延迟”的演讲而闻名,以“悲惨指标与后果”为题开启了会议。然后, Nobl9 公司的首席可靠性倡导者 Alex Hidalgo 接过话头,提出“放弃你的九”。最后,Honeycomb 公司的CTO Charity Majors 以会议中最生动且引人注目的方式表达了“P99 是胡说八道”。

那么 P99 存在什么问题呢?如果它们确实是胡说八道,那么我们应该考虑什么替代方案呢?

P99 CONF 2023 是一次关于低延迟工程策略的免费虚拟会议。在十月份,加入这个社区,深入探讨 Rust、可观测性、边缘计算、性能调优、人工智能/机器学习、Kubernetes、Linux 内核等主题,与众多来自令人惊叹的科技公司的工程师一起学习。

Gil Tene:我是如何学会不再担忧,而是热爱痛苦的

Tene 对 P99 “percentlies”(这是他的拼写,不是拼写错误)进行了批判,他用一个看似漂亮的图表开始了批判,这个图表充满了美丽的小谎言:

这个仪表板显示了两小时内的第 25、第 50、第 90 和第 95 百分位数,似乎很好地展示了发生的情况。引人注目的是,第 95 百分位数在 12:40 左右突然上升,第 90 百分位数稍微低于它,而其他百分位数似乎保持不变。你可能会认为这意味着有一些异常值需要探究,但根据 Tene 的说法,看这个图纯粹浪费时间。“这个图表没有显示的是比第 95 百分位数更差的 5% 的事情。这张图表显示的是好的东西;它只显示了愉快的结果。为了使这个图表甚至显示这种波动,情况必须非常糟糕,以至于我们看到的事物中有超过 5% 达到了这个水平。如果你想逃避现实或向他人掩盖现实,那么这就是你要展示的图表。如果你工作不好,但仍想要奖金,这是一个很好的图表。”

从糟糕到更糟

那么,引入 P99 后一切都好了吗?嗯,它确实提供了更多关于问题有多严重的见解。有了 P99,像这样的情况:

变成了这样:

但是,尽管现在看起来很糟,你仍然忽略了比这里显示的一切更糟的 1% 的事情。正如 Tene 所说:“只测量百分位数——通常是九个,只是为了深入到几个数字——是一种逃避现实的行为……如果你关心服务水平,关心终端用户、客户、企业看到的系统行为,那么你需要更深入地观察。”

当你测量 P99 时,你的终端用户(个人或客户)会经历比 99 百分位数更糟糕的情况的机会有多大?实际上相当大。P99 并不意味着 99% 的事情会比这更好。Tene 以一个非常简单的用户会话为例,其中只涉及平均每个页面加载 40 个资源的五次页面加载。多少用户不会经历比 HTTP 请求的第 99 百分位数更糟糕的情况?只有约 13%。换句话说,87% 的终端用户经历的情况比你的 P99 更糟糕。

这么多“九”

那么,你是否会沉迷于更多的“九”?嗯,这也有问题:“在我们测量的时间段内,数据点不足以用足够多的“九”分类。而且我们不倾向于跨数据集聚合事物,以从更大的数据中提取出更多的“九”。 Tene 提出了 HdrHistogram 来解决这个问题,使人们能够记录数据并将数据区间累积在一起以获得准确的“九”的数量。但他放弃了这个工具会被广泛采用的希望(“人们实际上使用良构直方图来获得更多“九”的机会并不太高”)。

虽然测量所有这些“九”很困难,但要做好更困难。这需要考虑到协同遗漏,这是一个比我们在这里可以充分讨论的大主题。简要总结一下:慢操作只测量一次,它引起的所有其他延迟的连锁效应根本不被测量。这严重扭曲了结果。

痛苦喜欢……更好的用户体验?

在这个绝望的低谷,Tene 停下来思考:“所以如果事情如此糟糕,我们似乎无法在这里做什么,我们该怎么办?我们要放弃吗?”幸运的是,不用。实际上,有些事情人们正在做确实有助于提供更好的体验。一个案例是“痛苦指标”。

考虑一下你的系统中失败的表现是什么样的,然后测量相应的“痛苦指标”。您可以可靠地测量指标,如超时、重试、失败的查询,甚至业务相关的指标,如放弃的购物车。如果这些数字趋势不好,那么你的 P99 是什么并不重要。显然有问题……去诊断和解决它!

Tene 总结了如何监测这些“痛苦指标”的方法。“绘制坏事,观察它,看它如何应对世界,看它如何应对负载。你的成功率是通过没有出现故障的事物的数量来衡量的。通常情况下,你会知道事情不够好。如果你不能在 50 毫秒内提供结果,用户将离开。如果你不允许他们在 5 秒内结账,他们会放弃。通常情况下,比所需更好并不是一种好处。但是稍微差一点就足以失去业务。”

这个总结只是皮毛。这是完整视频,所以你可以从“如何不测量延迟”的大师本人那里了解所有细节。

扔掉一些“九”

要了解有关测量 P99 的更多关键观点,可以查看 Charity Majors 的充满活力的 P99 CONF 主题演讲,以及 Alex Hidalgo 精心制作的关于所有“九”的探讨。还可以参考 Jessica Wachtel 的这篇优秀文章

Majors:你在没有戴眼镜的情况下在高速公路上行驶

早在演讲初期,Charity Majors 就坦言 P99 是胡说八道,因为每一次用户互动都重要。即使你达到了所有的“九”,“仍然可能会出现许多病态情况。今天登录的每个人可能都会发现他们的状态保存在一个不响应的分片上,支付可能会失败——几乎不会发生的事情有无限长的、细长的尾巴——但无论何时发生,它们都会必然伤害到你。”

与其沉迷于“九”,Majors 希望我们将目光投向内部,并专注于更好、更快地了解系统内部发生的事情。她说:“可观测性让你能够在非常细粒度的水平上检查因果关系。它将工作与产出、原因与效果联系起来,并帮助你使用放大镜进行迭代和改进。没有可观测性,你实际上是盲目驾驶,就像没有戴眼镜一样。”

她继续说:“实际上,只有非常小的一部分系统问题和错误实际上需要被密切了解。但这个小百分比对于你的业务的成功和用户的幸福有着巨大的影响。而棘手的部分在于你永远无法提前预测它们会是什么。”

这是梅杰斯丰富多彩解决方案的摘要:

她说:“实际上,这是赋予软件工程师拥有自己代码的能力,你做到这一点的方式是在进行工作时对其进行仪器化。除非你能够解释如何知道它是否会出错以及仪器化是什么……如果你能够这样做,以快速的反馈循环可靠地交付软件,你可能能够在用户之前捕获到 80% 以上的问题。”

需要注意的是,在许多方面,Majors 实际上与 Tene 强调的所谓的“痛苦指标”非常一致:“与其对数百个或数千个基于症状的监控检查发出警报,不如只在几个反映用户痛苦的宝贵的 SLO 上发出警报。”

Hidalgo:重新思考你的“九”们

剧透警告:Alex Hidalgo 并不是一个彻头彻尾的“九”恨者。他在 P99 CONF 的演讲中的一个关键观点是,如果你想改善真实世界用户在真实世界应用中的体验,那就要超越“九”。

P99 延迟侧重于标准的长尾分布,但正如伊达尔戈所经历的那样,情况并不总是这样。作为一名前 Google 站点可靠性工程师,他看到了各种各样的分布:双峰、左偏、多峰等等。如果你只看 P99,因为这是你一直在做的,那么你可能会错过很多。“使用九并不可怕,但它们并不总是正确的选择,”他解释道。“你需要有意义。”

但在这种情况下,有意义是什么意思呢?正如 Hidalgo 所说:“实际上,使用数字九是完全可以的。追求 99.9% 的可靠性没有问题。在测量延迟时使用第 99 百分位数绝对没有问题,因为在你的选择中变得有意义的一部分,以及在你的决策中变得有意义的一部分,是你应该寻求过去的经验。你只不过不想复制过去。有时候以前做的事实际上是一个非常好的主意。之所以有些事情如此常见——因为很多时候它们是正确的选择。你只需要确保它们对你来说是正确的选择。”

在 P99 CONF 23 继续讨论延迟

所以也许我们不需要扔掉所有的“九”——尽管在聊天中有些讽刺的言论,但我们还是保留了会议名称。;-)

如果你想继续关于测量和优化延迟的讨论,可以加入 P99CONF,那里不仅欢迎辩论,而且鼓励辩论。今年的讨论主题涵盖了如下领域:

  • Rust — 优化、案例研究、未来用例、Rust与C++、Zig、Go
  • Kubernetes — 数据库扩展、应用程序优化、边缘、基准测试
  • 数据库和事件流 — SQL、NoSQL、缓存、数据流
  • 人工智能/机器学习 — 特征存储、实时模型预测
  • 边缘 — 数据库、单内核、API网关
  • 可观测性 — eBPF、追踪、OpenTelemetry

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注