性能基础：理解性能指标与性能测试
在开始任何 profiling 与调优工作之前，必须先建立一套统一的“度量语言”。性能优化本质上是在约束条件下寻找最优解的过程，而约束条件正是由性能指标定义的。如果指标定义不清晰，后续所有的 profiling 数据都会失去参照意义。
核心指标：延迟、吞吐量与资源利用率
这三个指标构成了性能评估的“铁三角”。它们相互关联、彼此制约，单独看任何一个都可能导致误判。
- 延迟（Latency）：从请求发出到收到响应所经历的时间。通常关注的是尾部延迟（如 p99、p999），而非平均值——平均值会掩盖最差情况下的体验劣化。
- 吞吐量（Throughput）：单位时间内系统成功处理的请求数或事务数，常用 RPS（Requests Per Second）或 TPS（Transactions Per Second）表示。
- 资源利用率（Utilization）：CPU、内存、磁盘 I/O、网络带宽等资源被有效使用的比例。利用率过高（如 CPU 持续 95% 以上）往往意味着排队和延迟上升。
关键认知：延迟与吞吐量并非线性关系。当系统负载接近资源上限时，延迟会呈指数级恶化——这就是著名的“膝盖曲线”（knee curve）效应。调优的目标通常是在可接受的延迟范围内最大化吞吐量。
性能测试的方法与流程
性能测试不是简单地“压一压看会不会挂”，而是需要遵循一套严谨的方法论。根据目的不同，测试可分为：
| 测试类型 | 核心问题 | 典型场景 |
|---|---|---|
| 基准测试 | 系统在理想负载下的性能基线是多少？ | 版本发布前的回归对比 |
| 负载测试 | 在预期负载下，系统表现是否达标？ | 模拟日常峰值流量 |
| 压力测试 | 系统在极端负载下何时崩溃？ | 找出系统的极限上限 |
| 稳定性测试 | 长时间运行是否有内存泄漏或性能衰减？ | 7×24 小时持续运行验证 |
| 尖峰测试 | 系统能否应对突发流量冲击？ | 秒杀、热点事件 |
一个标准的性能测试流程通常包含以下步骤：
- 定义目标与指标：明确 SLA（如 p99 延迟 < 200ms，吞吐量 ≥ 1000 RPS）。
- 搭建隔离环境：测试环境应与生产环境在架构上等价，避免网络、存储等外部因素干扰。
- 设计测试场景：确定并发模型、请求分布、数据规模。
- 执行测试与监控：同时采集应用层指标（延迟、错误率）和基础设施指标（CPU、GC、I/O）。
- 分析瓶颈：利用火焰图、trace、日志定位热点。
- 调优与回归：每次改动后重新执行同一测试，确保改进有效且无副作用。
案例：一次典型的 Web 服务压测
假设我们有一个订单查询服务，使用 JMeter 进行负载测试。测试配置如下：
线程组：200 并发，持续 15 分钟
请求路径：GET /api/orders?userId=12345
采样间隔：每 5 秒记录一次聚合结果压测过程中发现：当并发数从 100 提升到 200 时，吞吐量从 850 RPS 增长到 920 RPS，但 p99 延迟从 180ms 飙升至 1.2s。进一步监控发现，CPU 利用率仅为 45%，但数据库连接池活跃连接数达到上限（50/50），大量线程阻塞在等待连接上。
分析结论：瓶颈不在应用 CPU，而在数据库连接池配置过小。将连接池上限从 50 调整到 120 后，重新压测，p99 延迟回落到 210ms，吞吐量提升至 1450 RPS。
这个案例说明：资源利用率低并不代表系统健康——它可能意味着某个共享资源（连接池、线程池、锁）已经成为隐形的瓶颈。
常见误区与复盘
误区一：只关注平均延迟。平均值会掩盖长尾问题。一个系统 p50 延迟只有 50ms，但 p99 可能高达 3s——对于真实用户来说，每 100 个请求中就有 1 个体验极差。必须同时报告 p50、p95、p99 甚至 p999。
误区二：压测时忽略“预热”阶段。JIT 编译、缓存填充、连接池初始化都会影响前几分钟的测试数据。正式记录数据前应预留 3～5 分钟的预热期，待指标稳定后再开始采样。
误区三：测试数据与生产数据差异过大。如果压测使用 100 条用户数据，而生产环境有 1000 万条，数据库索引效果、缓存命中率都会完全不同。测试数据应尽量模拟生产的数据量级与分布特征。
复盘时建议建立一份“性能测试检查清单”，每次压测前逐项确认：
- 是否已明确性能目标（延迟/吞吐量/错误率）？
- 测试环境与生产环境的差异是否已评估？
- 是否同时监控了应用层与基础设施层指标？
- 是否记录了 JVM/GC、连接池、线程池等中间层状态？
- 压测结果是否可重复？多次运行的标准差是否在可接受范围？