1. 压测认知：什么是压力测试、为什么需要压测、压测的核心指标
大家好，我是你们的老朋友。今天咱们聊聊压测最基础、也最容易被忽视的东西——认知。
说实话，我见过太多团队，一上来就甩脚本、上机器、跑并发。结果呢？数据一堆，但根本不知道在测什么。嗯，这就是典型的「知其然，不知其所以然」。所以这一章，咱们先把地基打牢。
1.1 什么是压力测试？
压力测试，说白了就是「故意找茬」。
你想想看，一个系统上线前，你总得知道它到底能扛多少人吧？就像你买一辆车，总得知道它最高能跑多快、能拉多重。压测就是干这个的——模拟真实用户，给系统施加越来越大的压力，直到它撑不住为止。
我个人习惯把压测分成三类：
- 负载测试：看看系统在正常流量下表现如何。比如平时1000人同时在线，能不能扛得住？
- 压力测试：往死里压，找到系统的极限。比如从1000人慢慢加到5000人，看什么时候崩。
- 稳定性测试：长时间跑，比如压它个72小时，看会不会内存泄漏、会不会越跑越慢。
我在项目中遇到过最典型的场景：一个电商平台，平时流量不大，但双十一那天突然爆了。为什么？因为没做压力测试，不知道系统在极端情况下的表现。嗯，那次事故之后，整个团队对压测的态度就变了。
1.2 为什么需要压测？
这个问题，我问过很多刚入行的朋友。答案五花八门，但核心就三点：
- 提前发现瓶颈：别等用户骂了才去修。压测能让你在线上出问题之前，就把数据库慢查询、线程池打满、内存溢出这些坑给填了。
- 评估系统容量：你总得知道系统能扛多少并发吧？不然你怎么做容量规划？怎么决定要不要加机器？
- 验证优化效果：改了个代码、调了个参数，到底有没有用？跑一遍压测，数据说话。
我曾经接手过一个项目，上线前没做压测。结果上线第一天，用户一多，数据库连接池直接打满，整个服务挂了两个小时。嗯，那天的值班电话，我到现在还记得。
1.3 压测的核心指标
聊完概念，咱们说说硬核的东西——指标。压测不看指标，等于白测。我个人最关注四个：QPS、TPS、RT、并发数。
1.3.1 QPS 和 TPS
这两个经常被混用，但其实有区别。
- QPS（Queries Per Second）：每秒查询数。一般用在读场景，比如一个搜索接口，每秒能处理多少次查询。
- TPS（Transactions Per Second）：每秒事务数。一般用在写场景，比如一个下单接口，每秒能完成多少笔交易。
说白了，QPS 偏「读」，TPS 偏「写」。但在实际项目中，很多人直接混着用，也没太大问题。我自己的习惯是：读接口看 QPS，写接口看 TPS。
举个例子：
# 假设一个接口，平均响应时间 50ms
# 那么单线程的 QPS = 1000ms / 50ms = 20
# 如果开 10 个线程并发，理论 QPS = 20 * 10 = 200
# 但实际会有锁竞争、网络开销，所以一般达不到理论值1.3.2 RT（响应时间）
RT 就是用户从发请求到收到响应的时间。这个指标最直观——用户觉得快不快，就看它。
我一般关注三个 RT 值：
- 平均 RT：所有请求的平均响应时间。但容易被极端值拉偏。
- P99 RT：99% 的请求都在这个时间内完成。这个更靠谱，能反映大多数用户的体验。
- 最大 RT：最慢的那个请求花了多久。偶尔看一眼，别太纠结。
1.3.3 并发数
并发数，就是同一时刻有多少个请求在处理。注意，是「在处理」，不是「在连接」。
很多人搞混了并发和连接。举个例子：
- 一个服务器能同时保持 10000 个 TCP 连接，但真正在处理请求的可能只有 100 个。
- 并发数，看的是那 100 个，不是 10000 个。
我自己的经验是：并发数不是越高越好。并发太高，线程切换开销大，RT 反而会飙升。所以压测时，要找到一个「最佳并发数」——在这个并发下，QPS 最高，RT 还能接受。
1.4 四个指标的关系
这四个指标不是孤立的。它们之间的关系，可以用一个公式概括：
QPS（或 TPS）= 并发数 / 平均 RT（秒）举个例子：
- 并发数 100，平均 RT 50ms（0.05 秒）
- 理论 QPS = 100 / 0.05 = 2000
但实际中，这个公式只是理想情况。因为系统有瓶颈，比如数据库连接池只有 50 个，那并发再高也没用。
下面这张图，是我自己总结的压测核心知识体系，你可以对照着看：
1.5 总结
这一章，咱们聊了压测的「是什么、为什么、看什么」。说白了，压测不是炫技，而是为了提前发现问题、评估容量、验证优化。核心指标就四个——QPS、TPS、RT、并发数，它们之间互相影响，要综合着看。
嗯，地基打好了。下一章，咱们聊聊压测工具的选择。到时候我会分享一些我踩过的坑，比如 JMeter 和 Locust 到底怎么选，什么场景用什么工具最合适。
想要更多资料，联系可可