3. 性能指标
性能调优的第一步，不是急着改代码，而是先回答一个根本问题：“当前系统到底慢在哪里？快又该如何度量？”如果连衡量标准都没有确立，任何优化都只是盲人摸象。本章聚焦四个最核心的性能指标——吞吐量、延迟、资源利用率、并发数，厘清它们的定义、测量方法以及彼此之间的制约关系。
核心原理：四个指标，一个系统
这四个指标并非孤立存在，它们从不同视角刻画同一系统的运行状态。理解它们的关系，比记住定义更重要。
- 吞吐量（Throughput）：单位时间内系统成功处理的任务量。常见单位有 QPS（每秒查询数）、TPS（每秒事务数）、BPS（每秒字节数）。它回答的是“系统干活的速率”。
- 延迟（Latency）：从请求发出到收到完整响应所经历的时间。通常关注平均值、P99（99%请求耗时低于该值）、P999 等分位数。它回答的是“单个请求等待多久”。
- 资源利用率（Utilization）：CPU、内存、磁盘 I/O、网络带宽等资源被有效使用的比例。它回答的是“系统硬件是否被充分或过度使用”。
- 并发数（Concurrency）：同一时刻正在处理中的请求数量（包括排队中与执行中的）。它回答的是“系统同时扛着多少任务”。
四者之间存在经典的Little's Law关系：并发数 = 吞吐量 × 平均延迟。这个公式揭示了系统内部的守恒关系——在稳定状态下，若延迟升高而吞吐不变，并发数必然上升；反之，若想降低延迟，要么降低吞吐，要么减少并发。
核心洞察：延迟是用户体验的直接感受，吞吐量是系统能力的体现，资源利用率是成本与瓶颈的指示器，并发数是连接前两者的桥梁。调优的本质，就是在四者之间寻找满足业务目标的平衡点。
测量方法：从工具到实践
每个指标都有对应的测量工具与注意事项。错误的测量方法比不测量更有害，因为它会给出虚假的安全感。
吞吐量的测量
吞吐量必须在稳定负载下测量，而非空闲状态。常用工具包括 wrk、ab、JMeter 等压测工具。测量时需注意：
- 压测时长应持续至少 60 秒，避免冷启动效应。
- 记录吞吐量的同时，必须记录此时的延迟分布，否则数据不完整。
- 区分“最大吞吐”与“饱和吞吐”——后者指延迟开始急剧恶化前的吞吐临界点。
延迟的测量
延迟不能只看平均值，平均值会掩盖长尾问题。正确的做法是记录百分位分布：
# 使用 wrk 测量 P99 延迟示例
wrk -t8 -c200 -d60s --latency http://target/api
# 输出中关注：
# Latency Distribution
# 50% 12.34ms
# 75% 18.90ms
# 90% 25.67ms
# 99% 48.21ms <-- P99 是关键指标测量延迟时，务必在客户端侧记录（而非服务端日志），因为客户端感知才代表真实用户体验。同时要区分网络延迟与服务处理延迟，可通过链路追踪工具（如 Jaeger、Zipkin）拆分。
资源利用率的测量
Linux 系统下使用 top、vmstat、iostat、sar 等命令。关键要点：
- CPU 利用率需区分
user、system、iowait、steal等不同状态。 - 内存利用率关注的是实际使用量，而非进程虚拟内存。
- 磁盘 I/O 关注
await（平均 I/O 等待时间）与%util，后者接近 100% 时说明磁盘饱和。
并发数的测量
并发数并非直接读取某个计数器，而是通过压测工具设置并发连接数，或通过中间件监控（如 Nginx 的 active connections）获取。更精确的方法是利用 Little's Law 推算：
并发数 = 吞吐量(QPS) × 平均延迟(秒)
# 示例：QPS=500，平均延迟=0.2s → 并发数=100案例场景：一次典型的 Web 服务压测
假设要对一个订单查询接口进行性能评估，压测结果如下：
| 并发数 | 吞吐量 (QPS) | 平均延迟 (ms) | P99 延迟 (ms) | CPU 利用率 |
|---|---|---|---|---|
| 50 | 820 | 61 | 95 | 45% |
| 100 | 1150 | 87 | 140 | 68% |
| 200 | 1210 | 165 | 380 | 92% |
| 400 | 980 | 408 | 1250 | 97% |
分析这张表可以发现：
- 并发从 50 增至 200 时，吞吐量仍在增长，但增速放缓，说明系统接近瓶颈。
- 并发达到 400 时，吞吐量下降，P99 飙升至 1.25 秒——系统已过饱和，出现排队与资源争抢。
- CPU 利用率在 92% 时吞吐已不再线性增长，说明 CPU 是主要瓶颈，但延迟恶化速度远快于吞吐下降速度。
调优启示：该接口的最佳工作点在并发 100～150 之间。此时吞吐接近峰值，P99 延迟仍在可接受范围（200ms 内）。盲目增加并发只会让延迟恶化，而吞吐几乎不增长。
误区与复盘：常见测量陷阱
在实际性能评估中，以下误区会导致结论完全错误：
误区一：只测平均值，忽略长尾。平均延迟 100ms 的系统，P99 可能高达 2 秒。对用户而言，每 100 个请求就有 1 个卡顿 2 秒，体验极差。必须同时报告 P50、P95、P99。
误区二：在低负载下评估系统上限。空闲系统的延迟毫无意义，必须加压至饱和点附近，才能暴露真实瓶颈。但也要避免压垮系统导致虚假数据——当错误率超过 5% 时，延迟数据已不可信。
误区三：混淆“并发连接数”与“并发处理数”。Nginx 显示 10000 个连接，但真正在执行业务逻辑的可能只有 200 个，其余都在等待 I/O。测量时需区分连接、请求、事务三个层级。
复盘清单：每次压测后，按以下步骤确认数据有效性：
- 检查错误率是否低于 1%（若高于则需排查异常）。
- 对比压测机资源利用率，排除压测机自身瓶颈。
- 验证 Little's Law：
并发数 ≈ 吞吐 × 延迟，若偏差超过 20%，说明测量存在误差或系统处于非稳定状态。 - 记录系统配置、压测参数、时间戳，确保结果可复现。