本章进度 14 / 18
78%
正文已完成
L289别用大 O 替代真实性能证据
综合数据规模、常数成本、内存、网络和用户等待判断是否值得优化。
把“复杂度”从听懂变成会判断，避免遇到真实任务时仍靠感觉选择。
建议先理解同主题上一课的核心概念，再完成本课判断练习。
- 无需安装新工具
- 准备一个可对照的真实问题或样本
复杂度能预警规模增长后的风险，却不能告诉你当前慢在哪里。网络往返、磁盘读取、序列化和第三方服务常常比本地算法更贵。优化前要先定义用户可感知指标并测量。
能区分增长风险与当前瓶颈，并为优化决定提出真实测量证据。
核心概念
先把关键判断说清楚
端到端时间优先
用户等待包含排队、网络、计算和渲染，单看某个函数耗时可能错过主要瓶颈。
时间与空间会交换
映射和缓存用更多内存换取更少重复计算，是否值得取决于命中率、更新频率和容量。
规模上限影响选择
已知最多 20 项的设置列表不必为百万级优化；会持续增长的日志和向量集合则要提前设预算。
案例拆解
排序不是接口慢的主因
团队看到接口中存在排序就计划改算法，但 95% 延迟实际来自串行请求三个外部服务。
- 01
用追踪拆分 DNS、网络、外部请求、本地计算和序列化耗时。
- 02
确认本地 500 项排序只占 2 毫秒，三个串行外部请求占 1.4 秒。
- 03
先并行无依赖请求并设置超时，再复测端到端 p95。
案例结果
用户等待显著下降，团队避免了对非瓶颈算法的无效重写。
提交前练习
现在轮到你
为一个“感觉慢”的流程制定最小性能诊断方案。
完成本课需要：完成以下内容用于本课收口。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
指标是页面可交互时间 p95；分段是API、数据库、本地转换、渲染；规模是100、1,000、10,000 条；门槛是本地转换超过总时延 25% 且随规模超线性增长才重写。
评分标准
- 指标能反映用户体验
- 分段覆盖外部与本地成本
- 优化门槛基于测量而非猜测
本课收口 · 应用检查
完成一次应用，再检查理解
完成一次必填练习，再通过理解检查；阅读标记和总结不设硬门槛。
你现在更接近哪一种状态？
尚有必填项未完成，请补齐后再继续。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- OpenTelemetry Signals↗official-docs · 核对日期 2026-08-23
- Monitoring Distributed Systems↗reference · 核对日期 2026-08-23