When Impressive Performance Gains Do Not Matter¶

Ch01.1545 When Impressive Performance Gains Do Not Matter¶

📊 Level ⭐⭐⭐ | 6.4KB | entities/when-impressive-performance-gains-do-not-matter.md

Colin Breck 以三个真实案例阐述了一个反直觉的工程洞察：数量级的性能提升可能完全不影响用户体验或业务结果。根本原因在于存在不易察觉的约束——人类注意力阈值、整数倍工作流约束、流水线反压机制。文章的核心教训是：性能优化的价值不在于百分比提升，而在于是否突破了关键阈值。

案例：数据库查询从 5-10 分钟优化到 30 秒-1 分钟——一个数量级的提升。

问题：人因研究表明，10 秒是保持注意力的极限。[^2] 超过此阈值，人们会切换任务——查看消息、去喝咖啡、开始另一个任务。无论是 5 分钟还是 30 秒，两者都远超 10 秒阈值，用户行为完全相同：切走，等几分钟或几小时后回来看结果。

结果：团队需要再一个数量级的改进（将查询压到 10 秒以内），才能真正改变用户的工作方式。最终他们做到了，多数查询在 10 秒内完成，部分原本会超时的查询也变得可行。

案例：通过自动化手动任务、移除不必要步骤、并行化和异步化，将一个流程从数小时优化到 1 小时以内——25-50% 的提升。

问题：类比水管工/电工/木工——如果一天工作 8 小时，单次工作加通勤就要 8 小时，节省 2-3 小时毫无意义。只有将单次工作压缩到 4 小时以下（含通勤），才能一天完成两个工作。从一到二的突破极其困难，过程中的效率提升不会产生回报，直到你真正突破阈值。

副产品：即使生产环境未突破，性能优化工作本身带来了质量和可靠性改进，且测试环境的性能提升加速了开发迭代。

案例：数据流水线（车辆、工厂设备、手机、金融交易 → 持久化日志 → 下游服务处理）中，工程师将单个阶段优化了数个数量级，但整体吞吐量没有变化。

机制：流水线中的慢速阶段会通过反压（backpressure）传导到上游阶段（这是设计行为）。如果存在多个瓶颈——这在大规模系统中很常见——整体吞吐量不会改善，直到每一个瓶颈都被移除。

方法论：从上游开始，逐步添加流水线阶段直到吞吐量下降。例如先从分布式日志读取事件后丢弃——如果这一步就达不到目标吞吐量，优化任何下游阶段都是浪费时间。

这篇文章的核心贡献是提出了阈值思维（threshold thinking）框架，与工程界普遍的百分比思维形成对比：

这与 Amdahl's Law 思想一脉相承——系统改进受限于不可并行化的部分。

Robert B. Miller 1968 年的论文 Response Time in Man-Computer Conversational Transactions 定义了三个关键阈值：

这些阈值在 58 年后的今天仍然有效，且经常被性能工程师忽视。

Breck 的注释揭示了一个重要模式：改进一个数量级已经极其困难，改进两个数量级的投入是非线性的。这与 Pareto 原则一致——最后 20% 的优化往往需要 80% 的投入。