第一章：压测基础认知
大家好，我是你们的老朋友。今天咱们聊聊压测最基础的东西。
很多人一听到「压力测试」，就觉得是拿工具怼着系统猛打。其实没那么简单。我见过不少团队，压测报告写得漂漂亮亮，上线第一天就挂了。为什么？因为基础认知没打牢。
什么是压力测试？
压力测试，说白了就是模拟真实用户，给系统施加越来越大的负载，看看它什么时候扛不住。
你想想看，一个系统平时跑得好好的，不代表上线后也能扛住。双十一、秒杀、突发流量……这些场景下，系统会不会崩？压测就是提前告诉你答案。
我个人习惯把压测分成三类：
- 负载测试：慢慢加压力，找到系统的「舒适区」
- 压力测试：持续加压，直到系统崩溃，找到极限点
- 稳定性测试：长时间跑，看有没有内存泄漏、连接池耗尽这类慢性病
嗯，这里要注意：很多人把负载测试和压力测试混为一谈。我在项目中遇到过，一个团队说做了压力测试，结果只是跑了10分钟的正常流量。那叫冒烟测试，不叫压测。
核心观点：压测不是「测一下能不能用」，而是「测一下什么时候不能用」。
压测的核心目标：TPS / QPS / RT
这三个指标，是压测的「三驾马车」。不懂它们，压测报告就是废纸。
| 指标 | 全称 | 含义 | 我的经验 |
|---|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数 | 一个事务可能包含多个请求，比如下单=查询库存+扣钱+生成订单 |
| QPS | Queries Per Second | 每秒查询次数 | 一般用于读场景，比如首页推荐、搜索 |
| RT | Response Time | 响应时间 | 用户感知最直接的指标，超过3秒用户就开始骂娘了 |
我曾经接手过一个项目，压测报告显示TPS有5000，看起来很漂亮。结果一查，RT已经飙到8秒了。你想想看，用户点个按钮等8秒才出结果，这系统能用吗？
所以，我建议你记住一个公式：TPS = 并发数 / RT。并发数上去了，RT也跟着涨，TPS可能反而下降。这就是系统的瓶颈点。
小技巧：压测时别只看TPS。我习惯把TPS和RT画在同一张图上。当RT开始陡增时，那个点就是系统的「膝盖」——再压就要跪了。
压测在研发流程中的位置
很多团队把压测放在上线前一周，匆匆跑一遍。这其实是个坑。我见过最惨的一次，压测发现数据库连接池配小了，改完配置重新上线，结果又引发了新的问题……
压测应该贯穿整个研发流程。我个人习惯这样安排：
- 需求阶段：定目标。比如「首页接口必须支持1000 QPS，RT小于200ms」
- 开发阶段：单接口压测。每个接口写完，本地跑一下，确保基础性能达标
- 联调阶段：链路压测。模拟真实业务流程，看看上下游有没有瓶颈
- 预发阶段：全链路压测。模拟线上流量，验证整个系统
- 上线后：持续监控。压测不是一次性的，每次大版本更新都要重新跑
为什么会这样？因为越早发现问题，修复成本越低。你在开发阶段发现一个慢SQL，改一下索引就完事了。等到预发阶段才发现，可能得改架构，那就麻烦了。
避坑指南：我曾经在预发阶段压测，发现TPS死活上不去。排查了半天，结果是压测工具所在的机器网卡带宽打满了。嗯，压测环境本身也要压测，这个后面会细讲。
知识体系总览
下面这张图，是我自己总结的压测知识体系。你可以把它当作整个课程的地图。
这张图里，基础认知是地基。地基不牢，后面全是空中楼阁。接下来的课程，我们会一步步深入每个模块。
好了，第一章就到这里。记住：压测不是炫技，是保命。你想想看，线上挂了再救，和上线前就发现问题，哪个成本低？
课后思考：你现在负责的系统，压测目标是多少？如果不知道，建议立刻去问产品经理。没有目标的压测，就是瞎忙活。