4. 性能工程基础与医疗场景指标

性能工程不是“上线前压一次”的临时动作，而是一套用指标描述系统行为、用数据驱动容量决策的持续方法。在医疗平台中，这套方法尤其重要：挂号、缴费、报告查询、医嘱开立、影像调阅等业务对延迟和可用性的容忍度差异极大，用同一套指标口径去衡量所有服务，往往会得出错误结论。本节先建立五个核心指标的准确定义与相互关系，再讨论医疗业务对延迟和可用性的特殊约束。

五个核心指标：定义与口径

响应时间指从客户端发出请求到收到完整响应所经历的时间，通常拆为网络传输、排队等待、服务处理、后端依赖四段。工程上更关注分位数而非平均值：P50 反映典型体验，P95/P99 反映长尾。医疗场景中，平均值常被少数慢请求掩盖，例如 1000 次请求中 990 次 80ms、10 次 3s，平均约 109ms 看似良好，但 P99 已达 3s，足以让急诊医生感到“系统卡住”。因此容量规划应以 P95/P99 为主要约束。

吞吐量指单位时间内系统成功处理的请求数（如 QPS、TPS）。它与响应时间并非独立：在固定资源下，吞吐量随并发上升而增长，到达拐点后因排队和资源争用反而下降。这个拐点就是系统的实际容量上限，也是压测要寻找的关键位置。

并发数指同一时刻正在被处理的请求数量。需区分“在线用户数”“并发连接数”和“活跃请求数”：10000 名在线用户可能只有 300 个活跃请求。容量估算应基于活跃请求数，而非注册用户数，否则会严重高估资源需求。

错误率指失败请求占比，需明确失败口径：HTTP 5xx、超时、业务校验失败是否计入。医疗系统中，超时往往比显式报错更危险，因为它可能造成“已扣费未挂号”这类状态不一致。建议将超时单独统计，并纳入错误率告警。

资源利用率指 CPU、内存、磁盘 IO、连接池、线程池等资源的使用比例。经验上，CPU 长期高于 70% 会显著放大排队延迟；数据库连接池使用率超过 80% 后，获取连接的等待时间会非线性上升。利用率不是越低越好，而是要在成本与余量之间取得平衡。

指标之间的耦合关系

五个指标不是并列的，而是通过“排队”这一机制耦合在一起。当并发数接近系统处理能力时，请求开始在队列中等待，响应时间上升；当队列溢出或线程耗尽，错误率开始攀升；同时 CPU、连接池利用率逼近上限，进一步恶化延迟。这就是典型的过载螺旋。容量规划的目标，是让系统在业务峰值并发下仍处于曲线拐点左侧，并保留 30% 左右的资源余量应对突发。

一个实用的判断方法是：在压测中逐步提升并发，记录每个并发档位的 QPS、P95 和错误率。当 QPS 增速明显放缓、P95 开始陡增时，该点即为拐点。例如某挂号服务在并发 200 时 QPS 为 1800、P95 为 120ms；并发升至 300 时 QPS 仅 1950、P95 升至 480ms；并发 400 时 QPS 回落至 1700、错误率升至 2.3%。此时应把 200～250 并发作为安全容量区间，而非 400。

医疗业务对延迟与可用性的特殊要求

医疗场景的指标约束不能一刀切，需按业务分级。以下为示例性分级建议，实际阈值应结合医院规模、网络环境和临床流程确认：

可用性目标需要换算成可接受的年停机时间：99.9% 约 8.76 小时/年，99.95% 约 4.38 小时/年，99.99% 约 52.6 分钟/年。急诊类业务若承诺 99.99%，意味着全年不可用时间不足一小时，必须依赖多活、快速故障转移和本地降级能力，而不能只靠单机高可用。

从指标到容量：一个可执行的估算示例

假设某三甲医院门诊挂号系统，历史数据显示周一上午 8:00–10:00 为峰值，活跃请求并发约 180，单请求平均处理时间 60ms。按利特尔法则估算所需处理能力：QPS = 并发数 / 平均响应时间 = 180 / 0.06 = 3000 QPS。若单实例在 P95 ≤ 1s 约束下可稳定承载 800 QPS，则至少需要 4 个实例；再考虑 30% 余量和故障冗余，建议部署 6 个实例，并配置连接池上限为单实例 120、数据库最大连接数不低于 720。

这些数字是示例性假设，真实项目必须用压测验证。压测时应固定数据集和请求分布，逐步加压，记录每个档位的 QPS、P95、错误率和资源利用率，最终形成“并发—吞吐—延迟—错误”四联表，作为容量基线和扩容触发依据。只有把指标口径、业务分级和压测数据三者对齐，性能工程才真正落地。