Day07-07｜2.9.1 性能指标：把“系统很快”变成可测量的架构目标

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

学习目标：掌握系统性能常用指标及其含义、关系和适用场景；理解响应时间、吞吐量、并发数、资源利用率、容量、可用性、延迟分位数和性能效率之间的区别；能够识别错误的性能表述，建立指标体系，并将指标映射到架构措施、测试方法和论文论证。

一、性能不是一个数字

在项目评审中，经常听到“系统性能很好”“接口很快”“能够支撑高并发”等表述，但这些话无法直接验证。性能必须依赖场景、负载、数据规模、软硬件环境和测量方法。一个接口平均响应 100 毫秒，可能有 1% 的请求超过 20 秒；一个系统每秒处理 1 万条消息，可能因为积压而无法及时完成；CPU 利用率 30% 也不代表用户体验良好。

系统架构师要把性能目标写成指标，并说明测量范围、统计方式和验收条件。性能分析通常覆盖用户体验、服务处理、资源消耗和系统容量四个层面。

二、响应时间与延迟

响应时间是从请求发出到收到完整结果所经历的时间。对网络服务而言，它可能包括排队、网络传输、网关处理、业务计算、数据库访问、外部调用、序列化和返回传输。平均响应时间容易理解，但会掩盖慢请求，因此应同时观察中位数、P90、P95、P99 等分位数。

中位数表示一半请求不超过该时间，P95 表示 95% 请求不超过该时间，P99 关注最慢的 1% 请求。用户体验和级联调用通常更受尾延迟影响。一个服务的 P99 较高，经过多个同步服务串联后，端到端尾延迟可能进一步放大。

响应时间还要区分端到端延迟、服务端处理时间和数据库执行时间。若只优化数据库，却忽略排队、网络和客户端渲染，用户看到的改善可能很小。架构文档应说明指标采集点和时间边界。

三、吞吐量与处理能力

吞吐量表示单位时间内系统完成的工作量，例如每秒请求数、每秒事务数、每秒消息数、每分钟文件数或每小时批处理量。吞吐量必须明确“完成”的定义，收到请求不代表业务已经成功，写入队列也不代表消息已经被消费。

吞吐量受数据规模、请求类型、成功率、资源配置和一致性要求影响。读请求和写请求的成本不同，简单查询和复杂报表不能混用一个平均值。测试时应建立代表性负载模型，记录吞吐、响应、错误、积压和资源变化。

最大吞吐不是越大越好。当系统进入饱和区后，队列和响应时间会快速增长，继续增加并发反而降低有效吞吐。架构师要区分稳定吞吐、峰值吞吐和极限吞吐，并为系统保留安全余量。

四、并发数、连接数与负载

并发数是同一时间处于处理或等待状态的请求、任务、用户或连接数量。并发不等于每秒请求数：低响应时间下每秒请求数可能很高，但并发较低；响应时间变长时，即使到达率不变，并发数也会增加。

在稳定状态下，可以用直观关系理解三者：并发量大致等于到达率乘以平均响应时间。该关系提醒我们，提升并发上限不一定提升处理能力；如果下游数据库连接池、线程池或消息消费者没有同步扩展，系统只会积累等待。

连接数包括客户端连接、HTTP 连接、数据库连接、消息连接和设备连接。连接池过小会导致排队，过大可能压垮下游或占用大量内存。架构设计要定义连接复用、空闲超时、最大连接、失败重连和限流规则。

五、资源利用率与瓶颈

资源利用率表示 CPU、内存、磁盘、网络、线程、连接池或其他资源的使用程度。利用率高不一定坏，低也不一定好。CPU 低但 I/O 等待高，说明瓶颈可能在磁盘或网络；内存充足但 GC 暂停严重，说明运行时行为影响尾延迟；数据库 CPU 不高但锁等待多，说明并发控制可能是瓶颈。

常见资源指标包括 CPU 使用率、负载、内存占用、堆和非堆、垃圾回收暂停、磁盘 IOPS、吞吐、队列长度、网络带宽、丢包、线程池活跃数、连接池等待和消息积压。单个指标不能解释系统，必须结合业务指标和调用链分析。

瓶颈可能是硬瓶颈，也可能是配置或架构瓶颈。增加机器只能解决部分资源不足，不能解决锁竞争、热点键、串行依赖、低效算法和不合理数据访问。性能优化要先测量、定位、验证，再决定是否扩容或改造。

六、容量、可扩展性与性能效率

容量是系统在规定资源、质量和约束下能够承载的最大工作量。容量规划需要考虑当前负载、增长趋势、峰值、故障冗余、数据保留和成本。不能把实验室基准直接当作生产容量，必须说明环境差异和安全余量。

可扩展性描述系统增加资源或改变结构后，处理能力是否能够有效提升。垂直扩展增加单机 CPU、内存或磁盘，简单直接但受上限和故障域限制；水平扩展增加节点，容量和故障隔离较好，但需要处理状态、数据分片、一致性、负载均衡和运维复杂度。

性能效率可以理解为单位资源带来的有效产出，例如每台服务器每秒完成的成功事务数。架构优化不应只追求峰值吞吐，还要关注资源成本、能耗、稳定性、故障余量和尾延迟。

七、可用性与性能目标的关系

可用性描述系统在需要时能够正常提供服务的程度，通常用正常运行时间占总时间的比例表示，也可结合故障率、平均修复时间和平均无故障时间分析。可用性不是性能指标，但二者经常相互影响。

过度追求低延迟可能减少重试和持久化步骤，损害可靠性；过度追求强一致和多副本同步可能增加延迟；限流和降级可以保护可用性，却可能降低部分请求的功能完整度。架构师需要定义不同业务等级的性能和可用性目标，而不是让所有请求使用同一标准。

八、性能指标的定义方法

一个完整指标至少包含对象、场景、负载、统计范围、目标值、测量点和验收方式。例如：“在生产等效环境中，订单查询场景、1000 并发用户、读写比例 8:2、数据量 1 亿条时，P95 响应时间不超过 500 毫秒，成功率不低于 99.9%，持续 30 分钟。”

这样的指标才可以指导架构设计和测试。若目标未说明数据量，索引优化可能在小数据上有效、在生产规模上失效；若未说明 P99，严重慢请求可能被平均值掩盖；若未说明错误率，系统可能通过丢弃请求获得表面吞吐。

九、案例：电商大促性能目标

某电商系统预计大促期间每秒 2 万次商品查询、每秒 2000 次下单，要求商品页 P95 不超过 300 毫秒，下单成功率不低于 99.9%，库存不能超卖。团队提出“所有服务扩容两倍”作为方案。

这个方案不完整。首先要把查询和下单分开建模，查询的缓存命中率、热点商品和 CDN 影响很大；下单涉及库存、价格、优惠、订单和支付，不能只用请求数衡量。其次要关注并发、队列、数据库锁、连接池、消息积压和下游支付延迟。扩容前要识别瓶颈和关键路径。

可以采用商品静态化和多级缓存降低查询压力，通过热点预热和限流保护源站；下单链路采用幂等、库存预扣或预占、消息削峰和异步通知；关键写操作仍需明确一致性边界。验收指标应包含 P50/P95/P99、成功率、库存准确性、消息积压、数据库锁等待、缓存命中率和故障降级效果。

十、练习与详细答案

1. 为什么平均响应时间不能代替 P99？
2. 吞吐量和并发数有什么区别？
3. CPU 利用率低是否说明系统性能没有问题？
4. 一个完整性能指标应包含哪些要素？
5. 为什么最大吞吐不一定是稳定可用吞吐？

答案：1. 平均值会掩盖尾部慢请求，P99 能反映极端用户体验和级联调用风险；2. 吞吐量是单位时间完成的工作量，并发数是同一时间处于处理或等待的数量；3. 可能存在 I/O、锁、网络、连接池、消息积压或运行时暂停等瓶颈；4. 至少包括对象、场景、负载、环境、测量点、统计方式、目标值、持续时间和证据；5. 饱和后排队增长、响应恶化和错误增加，极限状态下的瞬时数字不能代表长期稳定服务能力。

案例题：某接口平均响应 80 毫秒，但用户仍频繁反馈卡顿。监控发现 P99 为 8 秒，数据库平均 CPU 仅 40%。请分析原因并给出排查路径。

参考答案：平均值掩盖了尾部慢请求，原因可能是慢 SQL、锁等待、连接池排队、缓存击穿、网络重试、外部依赖超时、垃圾回收暂停或少量大请求。应按请求 trace 分解端到端时间，比较 P50/P95/P99，关联数据库执行时间、锁等待、连接池等待、网络和外部调用；按参数、租户、数据量、时间段和节点定位异常样本；检查慢查询、热点、重试和 GC 日志；在修复后用相同负载重新压测，验证 P99、错误率和资源指标，而不是只看平均值。

十一、论文素材与复盘

论文中写性能时，先给业务场景和可量化目标，再写容量模型、缓存、异步、分片、连接池、限流、降级或扩容措施，最后写 P95/P99、吞吐、成功率、积压和资源利用率等验证结果。不要只写“性能提升明显”，应说明测量范围和对比基线。

今日核心记忆句：响应时间看快慢，吞吐量看单位时间完成多少，并发数看同时有多少，资源利用率看消耗，容量看能承载多少，分位数看尾部体验，可扩展性看增加资源是否有效。性能目标必须绑定场景、负载、环境、统计方式和验收证据，架构措施必须针对瓶颈而不是盲目扩容。