性能基础：性能指标的定义与测量方法
性能优化工作开始之前，首先要回答一个根本问题：“快”与“慢”如何度量？没有量化指标，任何优化都只是主观感受。性能指标是连接用户体感与系统内部状态的桥梁，也是后续排查问题的“仪表盘”。本章聚焦三类最核心的指标——响应时间、吞吐量、资源利用率，并给出可落地的测量方法。
核心原理：三类指标的语义与关系
性能指标并非孤立存在，它们从不同视角刻画同一系统的运行状态。理解其定义与内在关联，是正确解读数据的前提。
- 响应时间（Latency）：从客户端发出请求到收到完整响应所经历的总时长。它直接反映用户体验，通常关注平均值、分位数（P95、P99）而非单纯均值，因为长尾延迟才是用户抱怨的根源。
- 吞吐量（Throughput）：系统在单位时间内成功处理的请求数或事务数，常用单位有 QPS（每秒查询数）、TPS（每秒事务数）。它衡量系统的处理能力，与并发用户数、请求复杂度强相关。
- 资源利用率（Utilization）：CPU、内存、磁盘 I/O、网络带宽等硬件资源被有效使用的比例。高利用率未必是坏事（说明资源被充分利用），但持续 100% 往往意味着瓶颈。
三者存在经典的Little's Law关系：并发数 = 吞吐量 × 响应时间。当系统处于稳定状态时，任意两个指标可推导第三个。例如，若 QPS=1000，平均响应时间=200ms，则系统内平均并发请求数为 200。这一关系帮助我们在压测时快速判断瓶颈方向：响应时间上升而吞吐量持平，说明系统已过饱和；吞吐量下降而响应时间上升，则可能发生排队或死锁。
测量方法：从埋点到采样
指标定义清晰后，关键在于如何准确测量。测量方式不当，数据本身就会误导判断。测量分为两类：在线埋点（生产环境实时采集）与离线压测（测试环境模拟负载）。
响应时间的测量
最可靠的方式是在客户端或网关层记录请求发起与结束的时间戳。注意避免在应用内仅测量业务代码段，而忽略网络传输、队列等待时间。推荐使用分布式追踪（如 Jaeger、Zipkin）获取端到端延迟分解。
// 伪代码：正确测量响应时间
long start = System.currentTimeMillis();
try {
// 调用远程服务或执行业务逻辑
processRequest();
} finally {
long cost = System.currentTimeMillis() - start;
metrics.timer("api.request").update(cost);
// 记录到 Prometheus / StatsD 等
}吞吐量的测量
吞吐量必须结合时间窗口与成功率统计。仅看原始计数无意义，需区分“成功吞吐”与“错误吞吐”。常用工具为压测平台（JMeter、wrk、Locust），生产环境则通过计数器（Counter）累加后按时间聚合。
资源利用率的测量
操作系统级指标使用 top、vmstat、iostat、pidstat 等命令，或部署 Node Exporter + Prometheus 统一采集。注意 CPU 利用率应区分 user、system、iowait，内存需关注 swap 使用情况而非仅看空闲内存。
| 指标类别 | 常用工具/命令 | 关键注意点 |
|---|---|---|
| 响应时间 | APM（SkyWalking）、Zipkin、自研埋点 | 关注 P99 而非平均值；排除客户端网络抖动 |
| 吞吐量 | JMeter、wrk、Grafana 计数器 | 区分成功/失败请求；压测需逐步加压 |
| CPU 利用率 | top、pidstat、/proc/stat | user 高→业务计算密集；sys 高→系统调用频繁 |
| 内存利用率 | free -m、/proc/meminfo | 关注 available 而非 free；swap 使用率需警惕 |
| 磁盘 I/O | iostat -x、iotop | 查看 await、%util；区分读写延迟 |
| 网络带宽 | sar -n DEV、iftop | 关注重传率与 TCP 连接队列溢出 |
案例：一次订单服务延迟排查中的指标误读
某电商团队反馈订单创建接口 P99 延迟从 200ms 飙升至 2s。初步查看监控面板，发现 CPU 利用率仅 30%，内存充足，磁盘 I/O 空闲。团队一度怀疑是网络问题或外部依赖故障。
进一步拆分指标后发现：
- 响应时间分解：等待数据库连接池获取连接耗时占 1.5s，而 SQL 执行仅 50ms。
- 吞吐量：应用 QPS 未明显变化，但数据库连接池活跃连接数持续打满。
- 资源利用率：数据库服务器 CPU 仅 20%，但连接数达到上限（默认 100），大量线程在阻塞等待。
根因是连接池大小配置过小，且业务代码在异常分支未正确释放连接。若仅看 CPU 或内存利用率，会完全错过瓶颈。此案例说明：资源利用率指标必须结合连接数、线程数、队列深度等中间态指标综合判断。
误区与复盘：测量中的常见陷阱
即使工具正确，测量方法不当仍会得到失真数据。以下是高频踩坑点：
- 只统计平均值：平均响应时间 200ms 可能掩盖 10% 请求耗时 5s 的严重长尾。必须增加 P95、P99 甚至 P999 分位统计。
- 压测时未预热：JIT 编译、缓存填充、连接池初始化会导致前几分钟数据偏低。正式压测前应进行 3~5 分钟预热，待指标稳定后再记录。
- 忽略垃圾回收暂停：Java 应用中 GC 日志显示的 STW（Stop-The-World）时间会直接拉长响应时间。测量时需同时采集 GC 频率与耗时。
- 资源利用率采样间隔过长：若 30s 采样一次，瞬时 100% CPU 峰值会被平均成 60%，掩盖毛刺问题。建议生产环境采样间隔 ≤ 10s，压测时 ≤ 1s。
- 并发数设置不当：压测并发数过低测不出真实上限，过高则导致超时堆积，数据不可用。建议从低到高逐步加压，观察吞吐量拐点。
性能指标体系的建立是一个持续迭代的过程。初期可先覆盖核心接口的响应时间与 CPU 利用率，随着系统演进逐步补充连接池、队列、GC 等细分指标。关键在于：每个指标都要能回答“如果它异常，下一步看什么”，形成可执行的排查路径，而非仅仅收集数据。