当令人印象深刻的性能提升无关紧要时

# 当令人瞩目的性能提升并不重要 来源：https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/ 在我职业生涯中参与过的所有工作中，性能优化是最有成就感的事情。我喜欢让系统更高效，尤其是当这能为客户开启全新的可能性时。我也发现，以实证方式理解系统是掌握系统运行基本原理的最佳途径之一——尤其是复杂系统在规模或负载下的交互方式。但性能工作最大的好处之一，是它带来的创造力——通过深入系统工作，人们往往能产生大量改进产品或服务的想法，其中大部分甚至与性能优化无关。 尽管提升性能总是令人愉悦，但某些激动人心的说法——比如“快10倍”、“效率高一个数量级”或“资源减少50%”——可能并不会带来你预期的效果，因为存在一些不总是显而易见或直观的约束。这篇文章将探讨其中三个约束。 ## 注意力阈值 最近，我改进了一个新数据库的查询性能，这个数据库用于向用户界面返回数据，以支持图表展示和交互式分析。我们的目标是让新数据库的响应时间比已使用多年的旧数据库提高一个数量级。旧数据库中最耗时的查询需要5到10分钟。经过数月的艰苦工程，我们将相同查询的完成时间缩短到30秒到1分钟——这是数量级级别的提升。[\[1\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn1) 向管理层展示这些性能提升时，数据会非常漂亮——以往需要10分钟的查询现在1分钟就能返回。然而，我坚持认为，除非我们再挤出另一个数量级的提升，否则这不会产生我们想要的影响。 人因研究指出，10秒是保持一个人注意力的极限。[\[2\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn2) 对于超过这个时长的延迟，人们会在等待期间切换到其他任务。[\[3\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn3) 因此，即使查询从前需要5分钟缩短到30秒，两者都远远超过了10秒的注意力阈值。在两种情况下，人们都会切换焦点——查看消息、去喝咖啡、开始聊天、开始另一个任务。当他们几分钟或几小时后回到原任务时，用户界面已经加载完成，但实际耗时已经无关紧要了。 最终，如果我们不能让查询在10秒内完成，我们的性能改进就不会对人们的工作方式产生实质性影响。在复杂系统中，将性能提升一个数量级往往已是极其艰巨的成就。[\[4\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn4) 遗憾的是，我们还需要另一个数量级的提升——查询必须在10秒内完成才能留住用户的注意力。[\[5\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn5) ## 从一跨越到二 多年前，我参与过一个项目，我们通过自动化人工任务、消除多余步骤、并行化部分流程，以及将某些步骤延迟到后续异步完成，实现了令人难以置信的效率提升。整个过程从耗时几个小时缩短到稳定在一小时以内——大约25%到50%的改进。我们当时为此兴奋不已。 然而，这个软件性能的提升实际上并没有影响整个流程，因为流程受到物流约束。举个例子：一个水管工、电工或木工，他们都需要在一个地点安排工作、前往该地点，然后完成工作。假设他们每天工作8小时，而完成一个地点的工作需要8小时，那么即使流程改进节省了2到3小时，也没有实质意义，因为他们仍然没有足够的时间前往下一个地点并完成新的工作。如果无法将每项工作的总时间（包括通勤）缩短到4小时以下，就无法一天完成两件。突破这样的阈值极其困难，而沿途的效率提升直到你真正突破界限时才会显现价值——从一跨越到二，往往难如登天。[\[6\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn6) ## 管道中的背压 许多企业的软件基础设施包含数据管道：来自各种源头（车辆、工厂设备、手机、金融交易）的事件被产出，然后可靠地处理，驱动其他服务和应用程序。事件通常被持久化到耐久日志中，下游服务从中消费并处理事件。为了在规模化场景下实现高吞吐量，日志必须分区，下游服务则使用批处理、流水线、并行化、高效内存分配、动态扩展等技术。 数据管道中的性能瓶颈很难发现，因为系统动态是相互关联的。按照设计，管道中某个缓慢的阶段会向上游阶段施加背压。[\[7\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn7) 如果管道中存在多个瓶颈（这类系统中很常见），除非最后一个瓶颈也被消除，否则整体吞吐量不会改善。 好的工程实践是将管道分解为多个阶段，理解每个阶段的性能动态和限制。但很多时候我看到工程师们失望地发现，他们把一个阶段的性能改进了多个数量级，却对整体吞吐量毫无影响。[\[8\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn8) 如果你想改进管道的吞吐量，唯一重要的数字是端到端吞吐量。 ## 结论 性能工作极具挑战性，但它也是深入理解复杂系统、打造更好产品的一门学科。[\[9\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn9) 只是要确保令人瞩目的性能提升实际能达到预期的效果。 如果你想留住人们的注意力，你只有大约10秒。如果整体增量是一个约束，百分比增益是不够的——你需要能够从一跨越到二。为了最大化存在背压的管道的吞吐量，通常需要解决所有瓶颈，而不仅仅是一两个。否则，在上述每个例子中，即使是数量级级别的性能改进也可能毫无意义。[\[10\]](https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fn10) --- 1. 我曾开发过多个原型，它们让我确信我们选对了架构，并且我们押注的技术将继续朝着正确的方向成熟。但构建生产系统总是比开发原型困难得多，过程中不可避免地会遇到意外。人们通常会低估这一点。埃隆·马斯克在评论电池制造时曾说过（https://x.com/elonmusk/status/1308284091142266881）：“大规模生产新技术的极端困难并未被充分理解。这比制造几个原型要难1000%到10000%。” ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref1) 2. 罗伯特·B·米勒1968年的论文《人机对话事务中的响应时间》（https://dl.acm.org/doi/10.1145/1476589.1476628）常被引用，后续研究也有扩展。0.1秒是感知即时反馈的阈值，约1秒是任务连续性的阈值，约10秒是维持整体任务注意力的阈值。通过进度指示器或时间估算等机制提供反馈，有助于保持人的注意力。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref2) 3. 我有一个理论：人们在任务的初始投入阶段愿意等待更长时间。例如，如果你在搜索机票，在搜索过程（可能耗时10秒或更多）中你会保持耐心，只要初始结果显示后其余流程很快完成。我不知道是否有研究尝试量化这一点。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref3) 4. 将任何工程化流程改进一个数量级都极其困难。改进两个数量级则难上加难。所需的投入通常是非线性的。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref4) 5. 最终，我们让大多数查询在10秒内完成，甚至包括一些以前因超时而无法执行的查询。除了数据查询延迟，元数据查询延迟和网页渲染时间也是提升整体性能的重要突破口。我希望我们还没有停止。通过改进异步IO和数据聚合，我们有可能将性能再提升一个数量级。如果是这样，当前需要几秒钟（过去需要几分钟）的查询将在1秒内返回。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref5) 6. 这是一个很好的例子，说明关注性能还带来了许多其他好处。由于对这个过程的全面关注，我们最终在质量和可靠性上做出了许多改进，直接影响了客户体验。在这样的情况下，不要低估即使微小的性能提升也能加快测试环境中的迭代速度，从而支持更快的新功能开发和缺陷修复，即便这些性能改进并非生产环境中所需的突破。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref6) 7. 参见 Reactive Streams（https://www.reactive-streams.org/）中关于软件系统中背压概念的正式定义。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref7) 8. 我发现理解这类系统动态和瓶颈的最佳方法是从起点出发，增量地加入管道步骤，直到吞吐量下降。例如，先从分布式日志中读取事件然后丢弃——如果连这个都无法达到期望吞吐量，那么优化任何下游阶段都是浪费时间。我经常感到惊讶的是，有很多工程师从下游开始，或者急于使用剖析工具，而不是采用这种第一性原理的方法。你可能关心下游基准——比如每秒可以向数据库插入多少行——但你需要从上游开始。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref8) 9. 仿真也是理解复杂系统（包括性能）的宝贵实践。参见 Marc Brooker 的博客《系统构建者的简单仿真》（https://brooker.co.za/blog/2022/04/11/simulation.html）和他的演讲《再试一次：弹性系统背后的工具与技术》（https://www.youtube.com/watch?v=rvHd4Y76-fs）。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref9) 10. 为什么博客顶部放那张图片？因为性能优化可不是闲庭信步？不，这篇博客是我坐在公园长椅上写的，那个景色就是我的视角。想留个美好的回忆。 ↩︎ (https://blog.colinbreck.com/when-impressive-performance-gains-do-not-matter/#fnref10)