基准测试(Benchmark)搭建：选择合适的基准工具、环境标准化、基线数据采集
说到基准测试，很多同学第一反应就是「找个工具跑一下」。嗯，我当年也是这么想的。结果呢？数据跑出来，团队里三个人三个结论，谁都不服谁。后来我才明白——基准测试不是跑个分，而是搭建一个可复现、可对比的测量系统。
说白了，你要让任何人、在任何时间、用同样的方法，都能得到差不多的结果。这才是基准测试的价值。
1. 基准工具怎么选？别只看名气
我见过不少团队，上来就选 JMeter 或 wrk，理由是「大家都在用」。但你想想看，你的业务场景是什么？是短连接还是长连接？是同步调用还是异步处理？
我个人习惯这样选型：
- HTTP/HTTPS 接口：wrk、wrk2 足够轻量，适合快速压测
- 数据库查询：sysbench、pgbench 更专业
- 消息队列：Kafka 自带的性能测试工具，或者自己写生产者消费者脚本
- 全链路场景：JMeter 或 Gatling，支持复杂编排
我的经验：别贪多。团队里统一 1-2 个工具就好。我在项目中遇到过，有人用 wrk，有人用 ab，结果压出来的 QPS 差 30%，排查半天发现是连接复用策略不同。
2. 环境标准化——这是最容易被忽视的坑
环境不一致，数据就是废纸。我曾经吃过这个亏：开发环境压测 2000 QPS，上线前预发环境只有 800。查了两天，发现预发环境的 CPU 降频策略没关。
标准化清单至少包括：
| 维度 | 标准化项 | 常见坑点 |
|---|---|---|
| 硬件 | CPU 型号、核数、内存、磁盘类型 | 虚拟机 vs 物理机，超线程是否开启 |
| OS | 内核版本、文件句柄数、网络参数 | net.core.somaxconn 默认 128 太低 |
| JVM | 堆大小、GC 策略、元空间 | 不同 GC 策略吞吐差异巨大 |
| 中间件 | 连接池大小、超时时间、线程数 | 默认配置往往不适合压测 |
| 网络 | 带宽、延迟、是否跨机房 | 跨机房压测结果不可信 |
注意：环境标准化不是一次性的。每次压测前，都要确认环境参数没变。我习惯写一个环境检查脚本，跑压测前先跑一遍，输出差异报告。
3. 基线数据采集——从「跑一次」到「跑一套」
很多人采集基线数据，就是跑一次，记个数字。这不够。为什么？因为单次结果有随机性。
我建议这样做：
- 预热阶段：先跑 1-2 分钟，让 JIT 编译、连接池、缓存都稳定下来
- 正式采集：连续跑 3-5 次，每次 5 分钟
- 数据清洗：去掉最高和最低，取中间值的平均值
- 记录上下文：把环境参数、工具版本、压测脚本都记录下来
举个例子，我常用的 wrk 命令：
# 预热 60 秒
wrk -t4 -c100 -d60s http://target/api
# 正式采集，跑 3 次
wrk -t4 -c100 -d300s --latency http://target/api > result_1.txt
wrk -t4 -c100 -d300s --latency http://target/api > result_2.txt
wrk -t4 -c100 -d300s --latency http://target/api > result_3.txt
核心指标：不要只看 QPS。延迟的 P99、P999，错误率，CPU 使用率，这些都要记录。我见过 QPS 很高但 P99 超时的案例，那叫「虚假繁荣」。
4. 知识体系：基准测试搭建的核心逻辑
下面这张图，是我自己总结的基准测试搭建流程。每次做新项目，我都会对着它过一遍：
5. 避坑指南——我踩过的那些坑
做基准测试这么多年，有些坑我是一步步踩过来的。分享几个典型的：
- 压测客户端成为瓶颈：我曾经用一台 4 核机器压 32 核的服务端，结果客户端 CPU 先打满了。记住，压测客户端资源要足够。
- 忽略网络开销：同一个机房和跨机房，延迟差 10 倍。基线数据一定要在目标环境采集。
- 忘记记录版本：有一次优化后性能提升 20%，但后来发现是中间件版本变了。从那以后，我每次压测都记录所有组件的版本号。
- 预热不够：JVM 的 JIT 编译需要时间，连接池也需要预热。不预热的数据，偏差可能达到 30% 以上。
小技巧：我习惯把基线数据存成 JSON 格式，包含时间戳、环境参数、压测结果。这样后续做回归对比时，可以直接用脚本比对，不用翻 Excel。
基准测试搭建，说白了就是「把测量这件事做规范」。工具选对、环境固定、数据采全，这三步走扎实了，后面的性能回归对比才有意义。否则，你拿到的数字，可能只是运气。
想要更多资料，联系可可