性能基准测试：如何定义基准、测试环境搭建、基准测试工具选型与使用
性能调优这件事，最怕的就是「凭感觉」。你改了一行代码，觉得快了，但快了多少？是网络波动还是真的优化了？没有基准，你就是在黑暗中开枪。
我刚开始做性能优化时，就吃过这个亏。有一次我优化了一个核心接口，自测感觉响应时间从 200ms 降到了 150ms，心里还挺美。结果上线后监控一看，比原来还慢。后来复盘才发现——我测试时用的数据量只有线上的十分之一，而且测试机器和线上机器的 CPU 型号都不一样。嗯，从那以后，我再也不敢跳过基准测试了。
2.1 什么是性能基准？
说白了，基准就是一把尺子。你用它量出系统当前的性能水平，然后才能知道优化到底有没有效果。
一个完整的性能基准，至少包含三个维度：
- 吞吐量：单位时间内能处理多少请求。比如 QPS（每秒查询数）、TPS（每秒事务数）。
- 响应时间：从发请求到收到响应，花了多久。通常看平均值、P99、P999。
- 资源消耗：CPU、内存、磁盘 I/O、网络带宽。别光看业务指标，资源打满了也是灾难。
核心原则：基准测试不是跑一次就完事。它需要可重复、可对比、可信任。你每次改完代码，都要在同样的条件下重新跑一遍，才能说「优化了 X%」。
2.2 如何定义基准？
定义基准，不是随便找个接口压一下就行。我见过太多团队，基准定义得模棱两可，最后测试结果根本没法用。
我个人习惯按这四步来：
- 确定被测对象：是单个接口、整个服务、还是全链路？范围越小，问题越容易定位。
- 确定关键指标：这个系统最关心什么？电商系统看下单成功率，流媒体看首帧时间，别什么都测。
- 确定负载模型：模拟什么样的流量？是平稳增长、突发峰值、还是周期性波动？
- 确定基线版本：拿当前线上版本作为基线，优化后的版本和它比。没有基线，优化就是空话。
小技巧：基准定义最好写成文档，团队内对齐。我曾经在一个项目里，开发说「接口优化了 30%」，测试说「没变化」，最后发现两个人测的接口路径都不一样。基准定义不清晰，后面全是扯皮。
2.3 测试环境搭建
环境搭建是基准测试里最容易被忽视的环节。很多人直接在开发机或笔记本上跑压测，结果数据漂移得离谱。
我建议你记住一句话：测试环境越接近生产，基准越可信。
具体来说，环境搭建要注意这几个点：
| 因素 | 要求 | 常见坑 |
|---|---|---|
| 硬件配置 | CPU 型号、核数、内存大小与生产一致 | 开发机是 M1，生产是 Intel，性能差异巨大 |
| 软件版本 | 操作系统、JDK、中间件版本对齐 | JDK 8 和 JDK 17 的 GC 表现完全不同 |
| 网络拓扑 | 压测机、被测服务、数据库在同一网段 | 跨机房压测，网络延迟占了 80% |
| 数据规模 | 数据库数据量、缓存命中率与生产接近 | 测试库只有 100 条数据，线上 1 亿条，索引效果天差地别 |
| 并发模型 | 连接数、线程池大小与生产一致 | 测试时 10 个线程，线上 200 个，锁竞争完全不同 |
避坑指南：我曾经在搭建环境时，忽略了 CPU 的「睿频」特性。测试机器是共享的，别人跑任务时 CPU 频率自动降低，导致我的测试结果忽高忽低。后来我强制锁频，数据才稳定下来。环境隔离很重要，别跟别人共用压测机。
2.4 基准测试工具选型
工具选型这件事，没有银弹。不同的场景，适合不同的工具。我这些年用过不少，挑几个有代表性的说说。
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| wrk | HTTP 接口压测 | 轻量、单机就能压出高并发 | 不支持复杂场景编排 |
| JMeter | 复杂业务流程压测 | 支持断言、参数化、分布式 | 资源消耗大，脚本维护成本高 |
| Locust | Python 生态、自定义逻辑 | 代码化压测，灵活度高 | 性能不如 wrk |
| ab | 快速验证 | 系统自带，开箱即用 | 功能简陋，不适合复杂场景 |
| sysbench | 数据库/系统级压测 | 支持 CPU、内存、磁盘、数据库 | 对应用层支持弱 |
我个人习惯是：快速验证用 wrk，复杂场景用 JMeter，数据库压测用 sysbench。别在一个工具上死磕，工具是拿来用的，不是拿来学的。
2.5 基准测试工具使用示例
光说不练假把式。我拿 wrk 举个例子，这是我最常用的 HTTP 压测工具。
安装很简单，Mac 上 brew install wrk，Linux 上编译一下就行。然后跑一个基本的压测：
wrk -t12 -c400 -d30s http://localhost:8080/api/order这个命令的意思是：12 个线程，400 个并发连接，持续压 30 秒。输出结果大概长这样：
Running 30s test @ http://localhost:8080/api/order
12 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.62ms 12.34ms 198.00ms 85.67%
Req/Sec 732.45 89.21 1.02k 70.50%
262500 requests in 30.00s, 1.02GB read
Requests/sec: 8750.00
Transfer/sec: 34.67MB你看，Latency 的平均值是 45.62ms，P99 大概在 100ms 左右（从 Max 和分布可以估算）。Requests/sec 是 8750，这就是吞吐量。
注意：wrk 默认只统计 HTTP 响应时间，不包含连接建立时间。如果你的服务有长连接复用，这个数据是准的。如果是短连接，实际延迟会比这个高。我一般会在压测前先 warm up 几秒钟，让连接池热起来。
如果你需要更精细的 P99 数据，可以用 wrk2，它是 wrk 的增强版，支持指定百分位延迟统计。
wrk2 -t12 -c400 -d30s -R10000 --latency http://localhost:8080/api/order-R10000 表示目标吞吐量是 10000 QPS，wrk2 会尽量维持这个速率，然后告诉你实际的延迟分布。这个比 wrk 的「尽力压」更有参考价值。
2.6 基准测试的核心流程
说了这么多，我把整个流程串起来，画了一张图。你照着这个流程走，基本不会出大问题。
这个流程里，我最想强调的就是第 6 步——回归验证。很多人优化完就跑一次测试，看到数据好了就收工。但性能测试是有随机性的，我建议至少跑 3 次，取中位数或者平均值。如果 3 次结果波动超过 10%，说明环境有问题，先排查环境再谈优化。
2.7 基准测试的常见误区
最后，我列几个我踩过的坑，你遇到了可以少走弯路。
- 只测平均值：平均值会掩盖长尾问题。P99 和 P999 才是用户体验的关键。我见过一个系统，平均延迟 50ms，但 P99 是 2 秒——用户感知到的就是卡顿。
- 忽略冷启动：JVM 需要 warm up，缓存需要预热。第一次压测的数据通常不准。我一般会先压 1-2 分钟，等数据稳定了再开始记录。
- 压测机成为瓶颈：如果你的压测机 CPU 打满了，那测出来的数据就不是服务端的真实水平。我习惯用 top 或 htop 监控压测机，确保它有余量。
- 不记录测试参数：每次压测的并发数、持续时间、数据量、机器负载，都要记录下来。不然你优化了一个月，回头想对比，发现上次的参数忘了，一切重来。
避坑指南：我曾经在一次压测中，发现 QPS 突然下降了 50%。排查了半天，最后发现是运维在压测期间执行了日志归档，把磁盘 I/O 打满了。从那以后，我每次压测前都会先检查系统负载，确保没有「背景噪音」。环境干净，数据才可信。
基准测试这件事，说白了就是「先测量，再优化」。没有准确的基准，你的优化就是盲人摸象。把基准定义清楚，环境搭稳定，工具选对，剩下的就是耐心和细心了。