一、压测基础认知：什么是压力测试？为什么需要它？
大家好，我是老张。做性能这行十几年了，每次跟新人聊压测，总有人觉得这玩意儿就是「拿工具发请求看报不报错」。嗯，这么说吧——如果你真这么想，那你的系统上线后大概率会出事。
压力测试，说白了就是模拟真实用户流量，把系统往死里怼。看看它在极限情况下还能不能扛得住。我见过太多项目，开发环境跑得飞起，一上线就被用户骂成狗。为什么？因为没压过。
1.1 什么是压力测试？
压力测试（Stress Testing）不是简单的「跑个脚本看看」。它是一门系统性的破坏艺术。你想想看，一辆车出厂前要撞墙测试，一栋楼盖好要抗震测试。那你的服务上线前，凭什么不测测它能扛多少并发？
我个人习惯把压测分成三类：
- 负载测试：看看系统在正常流量下表现如何
- 压力测试：持续加压，直到系统崩溃，找到那个「临界点」
- 稳定性测试：长时间跑，看有没有内存泄漏、连接池耗尽这类慢性病
我在项目中遇到过最典型的案例：一个电商平台，平时日活 10 万，压测时发现 2000 并发就挂了。后来一查，数据库连接池只配了 20 个。你说这上线了能不出事吗？
1.2 为什么需要压测？
这个问题我问过很多团队。答案五花八门，但核心就三点：
- 提前发现瓶颈：别等用户骂了才去修。压测能让你在线上出问题之前，就把 CPU、内存、IO、网络这些短板找出来。
- 验证容量规划：你买了 10 台服务器，到底能扛多少流量？压测给你一个「硬数字」。我建议每个季度至少做一次容量评估。
- 保障用户体验：用户不会等你。页面 3 秒打不开，他就走了。压测能帮你守住 RT（响应时间）这条生命线。
核心观点：没有压测的上线，就是裸奔。我曾经见过一个金融系统，上线前没压测，结果双十一当天直接宕机 2 小时，损失几百万。从那以后，我再也不敢跳过压测环节。
1.3 压测的核心目标
压测不是为了「跑个报告交差」。它的目标很明确：
- 找到系统的最大承载能力：到底能扛多少 QPS？多少并发？
- 定位性能瓶颈：是 CPU 满了？内存不够？还是数据库慢？
- 验证优化效果：改了代码、加了机器，效果到底怎么样？用数据说话。
- 建立性能基线：每次版本迭代后，对比基线数据，防止性能回退。
我的经验：压测报告里最重要的不是「最高值」，而是「拐点」。也就是系统从正常到开始恶化的那个临界点。找到它，你就知道什么时候该扩容了。
1.4 核心衡量指标
做压测，你得看懂这几个数字。不然就是瞎忙活。
| 指标 | 全称 | 说明 | 我的建议 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数，常用于读场景 | 关注峰值 QPS，别被平均值骗了 |
| TPS | Transactions Per Second | 每秒事务数，常用于写场景 | 一个事务可能包含多个请求 |
| RT | Response Time | 响应时间，单位通常是 ms | 看 TP99，别只看平均 |
| 并发数 | Concurrency | 同时处理的请求数 | 不是越大越好，要结合 RT 看 |
这里我要多说一句。很多人搞混 QPS 和 TPS。我举个例子：你下单买一件商品，这个「下单」是一个事务（TPS=1），但它可能包含了查询库存、扣减余额、生成订单等多个查询（QPS 可能大于 1）。说白了，TPS 是业务视角，QPS 是技术视角。
至于 RT，我习惯看 TP99。什么意思？就是 99% 的请求都在这个时间内完成。平均 RT 可能被几个慢请求拉高，但 TP99 能真实反映大多数用户的体验。我曾经优化过一个接口，平均 RT 从 500ms 降到了 200ms，但 TP99 还是 2 秒。后来一查，是有个慢 SQL 在作怪。
避坑指南：我曾经犯过一个错误——只看 QPS 不看 RT。结果 QPS 上去了，RT 从 100ms 飙到了 5 秒。用户反馈说「页面卡死了」。记住：高 QPS 低 RT 才是真本事。
1.5 知识体系总览
下面这张图，是我自己总结的压测知识框架。你把它理解了，后面学起来就顺了。
这张图把压测的「是什么、为什么、目标、指标」串起来了。你把它记在脑子里，后面学具体工具和排查方法时，就不会迷路。
1.6 小结
这一章我们聊了压测的基础。记住几个关键点：
- 压测不是跑脚本，是系统性的破坏性测试
- 核心目标是找瓶颈、定容量、保体验
- 四个指标要烂熟于心：QPS、TPS、RT、并发数
- 看指标要关注拐点和 TP99，别被平均值忽悠了
嗯，基础打牢了，后面我们才能聊怎么动手压、怎么排查问题。下一章我会带大家搭建一个压测环境，到时候咱们真刀真枪地干一场。