Day07-08｜2.9.2 性能计算：用模型估算容量、延迟与加速效果

教材定位：系统架构设计师教程（第 2 版）第 2 章“计算机系统基础知识”第 2.9.2 节。

学习目标：掌握性能分析中的基本计算关系；理解响应时间分解、吞吐量、并发数、利用率、加速比、可扩展性和容量估算；能够识别计算模型的前提条件，完成综合知识计算题，并将计算结果转化为架构决策和论文论证。

一、为什么架构师要会性能计算

性能测试告诉我们“测出来是多少”，性能计算帮助我们在设计阶段回答“如果负载增长会怎样”“需要多少节点”“哪个环节是瓶颈”“优化投入是否值得”。计算不能代替实测，但可以快速排除不合理方案，指导压测规模和资源预算。

性能计算最容易犯的错误是只记公式、不看前提。同一个吞吐数字，在请求大小、成功定义、数据量、缓存命中率和网络环境不同的情况下没有可比性。答题时应先说明场景和假设，再列关系、代入数据、解释结果和补充验证方法。

二、响应时间分解

端到端响应时间通常可以分解为排队时间、网络传输时间、网关处理时间、服务计算时间、数据库访问时间、外部依赖时间、序列化和客户端呈现时间。可以用如下文字表达：

端到端时间 = 排队时间 + 网络时间 + 各服务处理时间 + 数据访问时间 + 外部调用时间 + 呈现时间。

这个关系的价值在于定位优化方向。如果数据库执行只占总时间的 10%，即使数据库速度提升一倍，端到端收益也有限；如果大量时间用于排队，优先扩容消费者或减少锁等待可能比优化算法更有效。

串行调用的总时间近似为各环节时间之和；并行调用的关键路径时间近似为启动、调度和各并行分支最大耗时之和。并行化可以降低延迟，但会增加线程、连接、资源争用和错误处理复杂度，不能无限拆分。

三、吞吐量、并发和响应时间

在稳定状态下，可以用一个常见关系近似连接到达率、并发量和响应时间：并发量 ≈ 吞吐量 × 平均响应时间。如果系统每秒完成 200 个请求，平均响应 0.5 秒，则平均在途请求约为 100 个。这个关系可以用于估算线程池、连接池和网关并发，但必须注意它描述的是平均稳态，不适用于突发、持续排队或大量失败的情况。

到达率和完成率不一致时，队列会变化。若每秒到达 1000 个任务、只能完成 800 个，积压会以每秒 200 个的速度增加。短时间可以靠缓冲吸收，长期必须提高处理能力、削峰、限流或降低任务复杂度。

吞吐量要使用有效完成量而不是收到量。若系统为了提高数字而快速返回但后台任务大量失败，不能认为性能提升。性能报告应同时列成功吞吐、错误率、积压、平均和分位响应时间。

四、利用率与饱和

资源利用率可以粗略理解为实际忙碌时间占可用时间的比例。低利用率可能表示资源不足以外的瓶颈，如锁、I/O、下游等待或串行环节；高利用率说明资源接近饱和，继续增加负载会导致排队和延迟快速增长。

在排队系统中，服务利用率接近 100% 时，等待时间往往会急剧增加。因此容量规划不能把 CPU、连接池或磁盘配置到长期满载。要根据业务关键程度保留余量，并考虑单节点故障、流量峰值、发布期间资源变化和突发恢复。

瓶颈资源不一定是利用率最高的资源，而是限制有效吞吐的资源。一个 CPU 使用率 50% 的数据库可能因为锁等待限制事务；一个网络带宽 60% 的系统可能因单连接上限而受阻。必须把利用率与队列、等待和业务指标结合起来分析。

五、加速比与阿姆达尔定律思想

加速比表示优化前执行时间与优化后执行时间的比值。若原来任务耗时 100 秒，优化后 70 秒，加速比约为 1.43，时间减少 30%。架构师还要关注投入成本和副作用，不能只看加速比。

当程序只有一部分可以并行或优化时，整体加速受不可优化部分限制。设可优化部分占原时间比例为 p，优化部分获得 s 倍加速，则整体加速比可近似表示为：整体加速比 = 1 / ((1-p) + p/s)。例如只有 80% 的时间可并行，即使这部分无限加速，整体最多也约为 5 倍。这个思想提醒我们先找到关键路径和占比最大的瓶颈。

如果优化增加通信、同步和调度开销，实际收益会低于理论值。分布式拆分、并行计算和缓存都应把协调成本纳入模型。

六、容量估算

容量估算需要明确业务量、峰值系数、单位工作量、节点能力、冗余和安全余量。一个简单的节点数估算可以写成：节点数 ≥ 峰值处理量 ÷ 单节点稳定处理量，然后向上取整并叠加故障冗余和扩展余量。

例如业务峰值 6000 请求/秒，单节点经过生产等效压测稳定处理 800 请求/秒，则基础节点数至少为 8 个。若要求任意 1 个节点故障仍能承载峰值，并预留 25% 增长空间，实际部署不能只放 8 个，而要根据故障模型和资源比例计算。数据库、缓存、消息队列和网络都要分别估算，不能只估应用节点。

存储容量可按数据产生速率、保留时间、副本数、索引和备份估算。媒体或日志系统还要考虑压缩比、元数据、冷热分层和峰值突发。容量模型必须写清楚“逻辑容量”和“物理容量”的区别。

七、网络和存储性能计算

网络带宽需求通常与并发数、单连接平均码率、协议开销和峰值系数有关。视频系统不能只用平均观看码率，还要考虑多清晰度、突发、重传、CDN 回源和缓存命中。文件上传则要考虑文件大小、并发连接、完成时间和分片并行度。

存储性能除了容量，还包括 IOPS、顺序吞吐、随机访问、延迟和队列深度。数据库写入量较大时，日志、索引和副本会放大物理写入；读缓存命中率变化也会改变磁盘压力。架构设计不能只说“磁盘够大”，要同时说明性能和可靠性。

八、案例：在线票务系统容量估算

某票务系统活动开售时预计每秒 12000 次查询、每秒 1200 次下单。经过生产等效测试，单个查询服务节点稳定处理 1000 次查询/秒，单个下单节点稳定处理 150 次下单/秒。要求任意一个节点故障后仍能承载峰值，并预留 20% 增长空间。

查询基础节点数为 12，下单基础节点数为 8。若用“故障后仍满足峰值”的 N+1 思路，查询至少 13 个、下单至少 9 个；再考虑 20% 增长，不能简单只乘 1.2 后向下取整，应按部署策略向上取整并确认故障和增长是否同时发生。若把增长余量和故障余量都纳入，则查询可按 12000×1.2÷1000=14.4，向上为 15 个；下单为 1200×1.2÷150=9.6，向上为 10 个，并检查任一节点故障后的剩余能力是否满足要求。

但这个结果只是应用层初估。下单还受库存锁、数据库事务、支付依赖和消息队列限制；查询还受缓存命中率和热点商品影响。必须分别测量数据库、缓存、消息、网关和网络，并用压测验证 P95/P99、错误率和积压。

九、性能计算的答题步骤

第一步，列出场景、负载、时间范围、资源和目标；第二步，判断使用吞吐、并发、排队、容量或加速模型；第三步，写出公式和前提；第四步，代入计算并注意单位；第五步，向上取整、加入余量和冗余；第六步，解释瓶颈、风险和需要实测验证的部分。

单位错误是常见失分点。每秒、每分钟、每小时必须统一；字节和比特要区分；平均值和峰值不能混用；逻辑请求与物理读写不能混用。计算结果超过某个阈值时，还要说明模型是否已经失效，例如排队、缓存击穿或网络饱和会使线性关系不再成立。

十、综合练习与详细答案

系统每秒完成 500 个请求，平均响应时间 200 毫秒，稳态并发约是多少？
某任务原耗时 100 秒，其中 70% 可获得 5 倍加速，整体约加速多少？
峰值吞吐 5000/秒，单节点稳定吞吐 600/秒，基础节点应取多少？为什么不能直接部署 8 个？
到达率 1000/秒、处理率 800/秒，持续 10 分钟会积压多少？
为什么容量估算必须区分单节点能力和稳定单节点能力？

答案：1. 500×0.2=100 个；2. 1/((1-0.7)+0.7/5)=约 2.27 倍；3. 5000/600=8.34，基础至少 9 个，还要考虑故障、峰值波动、增长、下游能力和资源余量；4. 每秒积压 200 个，600 秒约积压 120000 个，实际还要考虑队列上限和失败重试；5. 极限能力通常伴随高利用率和长排队，无法代表长期稳定服务，容量应以满足质量目标的稳定能力为依据。

案例题：某服务扩容后吞吐没有提高，平均 CPU 降低但 P99 变差，请给出分析思路。

参考答案：扩容可能没有触及真正瓶颈，瓶颈可能在数据库锁、连接池、网络、共享缓存、下游服务或串行事务；节点增加也可能导致负载均衡不均、缓存命中下降、跨节点通信增加和一致性开销。应比较扩容前后到达率、有效吞吐、P50/P95/P99、队列、连接池等待、数据库锁、网络、缓存命中和下游延迟；沿 trace 找关键路径；检查单节点稳定能力、分片和热点；根据结果采用缓存、分片、异步削峰、限流、连接池调整或下游扩容，并用相同场景重新验证。

十一、论文素材与复盘

论文中可以用计算说明架构决策不是凭经验：根据峰值请求、单节点稳定能力和故障模型估算集群规模；根据并发和响应关系设置线程池、连接池和队列；根据响应时间分解定位瓶颈；用加速比思想判断优化优先级；最后通过生产等效压测验证模型。

今日核心记忆句：先定义场景和前提，再选模型和公式；并发约等于吞吐乘响应时间；整体加速受不可优化部分限制；容量要按稳定能力、峰值、冗余和余量估算；计算结果是决策依据，不是实测替代。高分答案必须写单位、假设、取整、风险和验证方法。