性能压测基础：压测目标定义、关键性能指标与压测环境搭建
大家好，我是你们的老朋友。今天咱们聊聊压测的基础。说实话，我见过太多团队一上来就甩开膀子压，压完拿一堆数据，结果啥也分析不出来。为什么？因为目标没定清楚，指标没选对。
这一章，咱们就把地基打牢。你想想看，盖楼不打地基，后面全是空中楼阁。
压测目标定义：你到底想测什么？
很多同学问我：「我该压多少并发？」我的回答永远是：「先问业务，再定目标。」
压测不是炫技，是验证。验证你的系统能不能扛住预期的流量。
核心原则：压测目标必须可量化、可复现、可验证。
我个人习惯把压测目标分成三个层次：
- 容量目标：系统能支撑的最大并发用户数或 QPS。比如「双十一峰值 10 万 QPS」。
- 稳定性目标：在目标负载下持续运行 N 小时，无 OOM、无核心功能降级。
- 延迟目标：P99 延迟不超过 500ms，P999 不超过 2s。
我在项目中遇到过最典型的翻车案例：某团队压测目标写的是「支持 1000 并发」，结果压测工具配了 1000 个线程，服务端直接挂了。后来一查，业务场景是长连接推送，1000 并发意味着 1000 个 TCP 连接同时在线，跟短连接的 1000 QPS 完全是两码事。
避坑指南：我曾经因为没区分「并发用户数」和「并发请求数」，导致压测结果跟线上表现差了 10 倍。记住：并发用户数 ≠ QPS。一个用户可能发多个请求。
关键性能指标：看懂这些数字
指标选不对，压测白费。咱们一个一个说清楚。
QPS 与 TPS
这两个词经常被混用，但本质不同。
| 指标 | 全称 | 含义 | 适用场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的 OLAP 查询 |
| TPS | Transactions Per Second | 每秒事务数 | 包含读写的事务型操作 |
说白了，QPS 侧重「查」，TPS 侧重「做完一件事」。在 OLAP 场景里，我一般更关注 QPS，因为大部分操作是查询。但如果你做的是数据导入或 ETL 压测，TPS 才是你的菜。
P99 延迟
平均延迟是骗人的。你想想看，100 个请求里 99 个 10ms，1 个 10s，平均才 110ms，看着挺美，但那个倒霉的用户已经骂娘了。
P99 延迟的意思是：排在前 99% 的请求都小于这个值。换句话说，只有 1% 的请求比它慢。
我的经验：压测时同时关注 P50、P99、P999。P50 代表「大多数用户」的体验，P99 代表「最差的那 1%」，P999 代表「极端情况」。如果 P999 比 P99 高了一个数量级，说明系统有严重的长尾延迟问题。
吞吐量
吞吐量是系统在单位时间内处理的数据量。对于 OLAP 系统，常用 MB/s 或 GB/h 来衡量。比如「每小时导入 500GB 数据」。
吞吐量和 QPS 的关系就像高速公路：QPS 是车流量，吞吐量是总货运量。一辆大货车（高吞吐）可能只算 1 个 QPS，但拉了 10TB 数据。
记住这个公式：吞吐量 = QPS × 单次请求数据量。优化时，这两个变量都要考虑。
压测环境搭建：别在「假环境」上浪费时间
环境不对，压测结果就是废纸。我见过最离谱的事：压测环境用 4 核 8G 的虚拟机，线上是 64 核 512G 的物理机，然后拿着压测数据去评估线上容量。这不是扯淡吗？
环境搭建的黄金法则
- 硬件等比缩放：如果线上是 32 核，压测环境至少 8 核。CPU、内存、磁盘 IO 的比例要尽量一致。
- 网络隔离：压测机和目标服务尽量在同一机房或同 VPC，避免公网延迟干扰。
- 数据量级匹配：压测数据量至少是线上数据量的 1/10，否则索引效果、缓存命中率都会失真。
避坑指南：我曾经在压测环境里用了线上 1% 的数据量，结果查询全部走内存，P99 延迟 20ms。上线后数据量大了 100 倍，磁盘 IO 打满，P99 直接飙到 5s。教训：数据量不够，压测就是自欺欺人。
压测工具选型
工欲善其事，必先利其器。我常用的压测工具有这些：
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Apache JMeter | HTTP 接口、JDBC 查询 | 图形化界面、插件丰富 | 分布式压测配置复杂 |
| wrk | HTTP 短连接压测 | 轻量、单机并发高 | 不支持复杂场景编排 |
| sysbench | 数据库 OLTP 压测 | 内置多种测试模型 | OLAP 场景支持弱 |
| 自研脚本 | 定制化 OLAP 查询压测 | 完全可控 | 开发成本高 |
我个人习惯用 JMeter 做基础压测，再用自研脚本模拟复杂的 OLAP 查询模式。为什么？因为 OLAP 查询不是简单的 GET/POST，它涉及 SQL 解析、查询计划生成、数据扫描、聚合计算等多个阶段，标准工具很难模拟真实行为。
一个典型的压测环境架构
下面这张图是我常用的压测环境部署结构，你一看就明白：
这个架构的核心思路是：压测客户端无状态、查询节点可扩展、存储层共享。你想想看，如果压测客户端有状态，每次请求都绑定到同一个查询节点，那还测什么负载均衡？
环境搭建 Checklist
每次搭建压测环境，我都会过一遍这个清单：
- 硬件确认：CPU 核数、内存大小、磁盘类型（SSD/HDD）、网络带宽
- 软件版本：OLAP 引擎版本、JDK 版本、操作系统内核参数
- 数据准备：数据量、数据分布、索引状态、分区策略
- 监控部署：Prometheus + Grafana，至少监控 CPU、内存、磁盘 IO、网络、GC
- 基线记录：压测前记录一次空载状态下的系统指标
小技巧：我习惯在压测脚本里加一个「预热阶段」，先跑 5 分钟低并发请求，让 JIT 编译、缓存、连接池都热起来。否则前几分钟的数据全是冷启动，没有参考价值。
本章小结
压测基础就这些。说白了，目标定清楚、指标选对、环境搭好，后面的事情才能顺。别急着上高并发，先把这三件事做扎实。