设备远程证明服务压测与优化 - 第1节
一、压测基础认知：什么是性能压测
性能压测，说白了就是「给系统找麻烦」。
你想想看，一个服务上线前，我们得知道它到底能扛多少压力。就像造一座桥，总得知道它能过多少辆车、能扛几级风。压测干的就是这事——模拟真实用户流量，把系统往极限推，看它什么时候撑不住。
我入行那会儿，有个同事上线前拍胸脯说「系统绝对没问题」。结果上线第一天，用户量一上来，数据库连接池直接打满，整个服务挂了半小时。嗯，从那以后，我再也不敢不做压测就上线了。
1.1 压测到底在测什么
简单说，压测就是回答三个问题：
- 系统能处理多少请求？ —— 吞吐量
- 请求处理得快不快？ —— 响应时间
- 能同时服务多少人？ —— 并发数
这三个指标，是压测的「铁三角」。任何一个出问题，用户体验都会崩。
核心观点： 压测不是「跑个脚本看看结果」，而是通过可控的压力，提前发现系统的性能瓶颈。你测出来的数据，决定了系统能不能上线、要不要扩容、需不需要优化。
1.2 压测的三种常见类型
| 类型 | 目的 | 典型场景 |
|---|---|---|
| 负载测试 | 验证系统在预期负载下的表现 | 日常流量、促销活动 |
| 压力测试 | 找到系统的极限承受能力 | 双11、秒杀 |
| 稳定性测试 | 验证系统长时间运行是否正常 | 7×24小时运行 |
我个人习惯，每次大版本上线前，三种测试至少各跑一轮。别嫌麻烦，线上出问题才真叫麻烦。
二、压测的核心目标
压测不是瞎跑，你得盯着三个核心指标。我一个个说。
2.1 吞吐量（Throughput）
吞吐量，就是系统单位时间内能处理多少请求。常见单位有：
- TPS（Transactions Per Second）：每秒事务数
- QPS（Queries Per Second）：每秒查询数
- RPS（Requests Per Second）：每秒请求数
举个例子，一个电商系统的下单接口，TPS 是 1000，意思就是每秒能处理 1000 笔订单。低于这个数，用户就得排队等。
我的经验： 吞吐量不是越高越好。你得结合硬件成本来看。我曾经见过一个团队，为了把 TPS 从 5000 提到 5500，多花了 30% 的服务器成本。值不值？你自己算算。
2.2 响应时间（Response Time）
响应时间，就是用户发一个请求，到收到响应花了多久。通常看这几个值：
- 平均响应时间：所有请求的平均值
- TP95 / TP99：95% / 99% 的请求在多少毫秒内完成
- 最大响应时间：最慢的那个请求花了多久
我建议你重点关注 TP99。为什么？因为平均响应时间容易被「长尾请求」拉偏。举个例子，100 个请求里 99 个是 10ms，1 个是 10s，平均下来还是 100ms 左右，但那个 10s 的请求已经让用户摔手机了。
避坑指南： 我曾经在一个项目中，只看平均响应时间，觉得系统挺快。结果上线后用户投诉不断。一查 TP99，好家伙，直接飙到 5 秒。从那以后，我每次压测报告里必须带上 TP99 和 TP95。
2.3 并发数（Concurrency）
并发数，就是系统同时能处理多少个请求。注意，这里说的是「同时处理」，不是「同时连接」。
很多人搞混这两个概念。我给你打个比方：
- 同时连接：就像餐厅里坐了 100 个人，但只有 10 个厨师在炒菜
- 同时处理：就是那 10 个厨师每人同时炒一道菜
并发数上不去，通常是因为：
- 线程池太小
- 数据库连接池不够
- 锁竞争激烈
记住这个公式： 并发数 = 吞吐量 × 平均响应时间。三个指标是联动的，改一个，另外两个也会变。
三、压测在软件生命周期中的位置
压测不是最后才做的事。它应该贯穿整个软件生命周期。我画了一张图，你看完就明白了。
3.1 需求阶段：定目标
产品经理说「系统要支持 10 万用户」。你得问清楚：
- 这 10 万用户是同时在线，还是日活？
- 核心接口的响应时间要求是多少？
- 有没有促销活动、流量波峰？
没有明确的目标，压测就是瞎跑。我见过太多项目，需求阶段不提性能指标，最后上线前才发现扛不住，只能紧急扩容，成本翻倍。
3.2 设计阶段：定方案
架构设计时，就要考虑压测。比如：
- 数据库要不要分库分表？
- 缓存层怎么设计？
- 服务要不要做限流、降级？
这些决策直接影响系统的性能上限。设计阶段不考虑，后面改起来成本极高。
3.3 开发阶段：写脚本
我建议开发同学在写业务代码的同时，就把压测脚本写好。别等到测试阶段再临时写脚本，那时候时间紧、压力大，容易出纰漏。
3.4 测试阶段：跑场景
这是压测的主战场。你要跑：
- 单接口压测
- 混合场景压测
- 稳定性压测
- 异常场景压测（比如某个服务挂了）
3.5 预发布阶段：做验收
预发布环境要和线上环境尽量一致。我踩过这个坑——预发布环境配置比线上低，压测结果看起来很好，上线后直接被打趴。
3.6 上线阶段：灰度验证
上线后，先放一小部分流量进来，观察系统表现。没问题再逐步放量。这叫「灰度发布」，也是压测的一部分。
3.7 运维阶段：持续压测
系统上线不是终点。业务在变，流量在变，代码也在变。你需要：
- 定期跑压测，验证系统性能是否退化
- 监控线上指标，发现异常及时处理
- 容量规划，提前扩容
我的习惯： 每周五下午跑一次全链路压测，持续 30 分钟。这样能及时发现本周代码变更带来的性能问题。别等到周一早上才发现系统变慢了。
四、总结一下
压测基础认知，说白了就三件事：
- 压测是什么 —— 模拟流量，找系统瓶颈
- 压测看什么 —— 吞吐量、响应时间、并发数
- 压测什么时候做 —— 从需求到运维，贯穿始终
嗯，这一章的内容就到这里。记住一句话：压测不是测试的事，是整个团队的事。