第二章 性能基准测试：如何建立科学的性能基准？
性能优化这件事，最怕的就是「凭感觉」。
我见过太多团队，上来就改代码、调参数，改完一看——好像快了？但快了多少？不知道。是不是因为负载降低了？也不清楚。说白了，没有基准，优化就是瞎忙活。
这一章，我们就聊聊怎么建立科学的性能基准。我会把工具选型、环境搭建、数据采集这些事，掰开了讲清楚。
2.1 为什么需要性能基准？
先问个问题：你凭什么说系统变快了？
凭感觉？凭用户反馈？都不靠谱。用户说「感觉快了」，可能是今天网速好。你说「好像吞吐上去了」，可能是测试机配置不一样。
基准测试的核心价值，就是提供一个可重复、可对比、可量化的参照系。
基准测试三要素：
- 可重复：同样的条件，跑十次结果差不多
- 可对比：优化前后，用同一套标准衡量
- 可量化：不是「快了」，而是「QPS从2000提升到3500」
我个人习惯，每次接手一个新系统，第一件事就是跑一轮基准。不是为了看它有多快，而是为了知道——它现在到底什么水平。
2.2 基准测试工具选型
工具选不对，后面全白费。市面上工具很多，但各有各的脾气。我按场景给你捋一遍。
2.2.1 HTTP接口压测：wrk vs ab vs JMeter
| 工具 | 特点 | 适合场景 | 我的评价 |
|---|---|---|---|
| wrk | 轻量、高性能、支持Lua脚本 | 快速压测、单接口调优 | ⭐ 日常首选 |
| ab (Apache Bench) | 简单、自带、但功能有限 | 快速验证、临时测试 | ⭐ 应急可用 |
| JMeter | 功能全面、支持复杂场景、GUI | 全链路压测、复杂业务流程 | ⭐ 大项目必备 |
wrk 是我用得最多的工具。它用多线程+事件驱动，单机就能压出很高的并发。而且支持Lua脚本，可以自定义请求参数、处理响应。
我的小技巧： wrk 的 Lua 脚本里，可以加一些随机参数，模拟真实用户行为。比如随机取用户名、随机商品ID，这样压出来的数据更有参考价值。
ab 呢？说实话，功能太简陋了。但它有个好处——几乎所有Linux系统都自带。应急用一下还行，别当真。
JMeter 是重量级选手。我曾在项目中用它模拟200个用户同时下单、支付、查询的完整流程。GUI界面虽然看着笨重，但做复杂场景时，比写脚本省事多了。
2.2.2 数据库压测：sysbench
数据库的基准测试，我几乎只用 sysbench。它支持MySQL、PostgreSQL、甚至文件系统IO的测试。
举个例子，测一下MySQL的读写性能：
# 准备数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=127.0.0.1 \
--mysql-user=root \
--mysql-password=123456 \
--mysql-db=test \
--table-size=1000000 \
prepare
# 运行测试
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=127.0.0.1 \
--mysql-user=root \
--mysql-password=123456 \
--mysql-db=test \
--threads=16 \
--time=60 \
run
# 清理数据
sysbench /usr/share/sysbench/oltp_read_write.lua \
--mysql-host=127.0.0.1 \
--mysql-user=root \
--mysql-password=123456 \
--mysql-db=test \
cleanup输出结果里，重点关注 transactions（每秒事务数）和 latency（延迟分布）。
注意： sysbench 的默认配置可能不适合你的场景。比如 --table-size 太小，数据全在内存里，测不出磁盘IO的真实瓶颈。我曾经踩过这个坑，压出来的结果漂亮得很，上线直接崩了。
2.3 测试环境搭建
环境不对，数据白费。我总结了几条铁律：
- 压测机与被测系统分离：别在同一台机器上又压又测，资源争抢会污染数据
- 网络延迟要可控：最好在同机房或同VPC内，避免公网抖动
- 预热环节不能省：很多系统有JIT编译、缓存预热，直接压测会偏低
- 监控要同步开启：CPU、内存、IO、网络，一个都不能少
我个人习惯，压测前先跑一轮「空转」——就是系统正常运行但不加压，看看基线负载是多少。这样压测时的增量数据才真实。
2.4 数据采集与指标解读
数据采集中，最容易犯的错误是「只看平均值」。你想想看，平均延迟100ms，听起来不错。但如果有1%的请求延迟到了5秒，用户体验就是灾难。
我建议关注这几个指标：
| 指标 | 含义 | 关注点 |
|---|---|---|
| QPS/TPS | 每秒请求数/事务数 | 吞吐能力的核心指标 |
| P50/P95/P99延迟 | 50%/95%/99%请求的响应时间 | P99比平均值更有意义 |
| 错误率 | 失败请求占比 | 超过1%就要警惕 |
| 资源利用率 | CPU、内存、IO、网络 | 找出瓶颈在哪 |
一个真实案例： 我曾经优化一个支付接口，平均延迟从200ms降到了80ms，团队都很高兴。但我看了P99延迟——还是1.2秒。后来发现是某个第三方回调偶尔超时，拖了后腿。如果只看平均值，这个问题根本发现不了。
2.5 本章知识体系
下面这张图，帮你理清基准测试的完整流程：
2.6 避坑指南
最后，分享几个我踩过的坑：
- 不要只跑一轮：至少跑3-5轮，取中位数。单次结果可能有偶然因素
- 不要忽略预热：很多系统前几秒的性能数据是假的，等稳定了再记录
- 不要改完配置直接比：每次改完配置，重启系统后，先跑一轮「基线验证」，确保环境没变
- 不要只看吞吐不看延迟：高吞吐+高延迟，对用户来说就是慢
我曾经犯过的错： 有一次优化数据库连接池，改完配置后QPS从3000涨到了5000，我高兴坏了。结果仔细一看，P99延迟从200ms飙到了2秒。原来连接数开太大，数据库CPU被打满了，大量请求在排队。这就是典型的「虚假吞吐」——数字好看，用户体验一塌糊涂。
基准测试这件事，说白了就是「先测量，再动手」。没有基准的优化，就像蒙着眼睛开车——你以为在前进，其实可能一直在原地打转。
下一章，我们会聊聊怎么分析这些数据，找到真正的性能瓶颈。到时候见。
想要更多资料，联系可可