📚 课程目录第3章压力测试基础

3、压力测试基础

讲到压力测试，很多人会问：这和性能测试有什么区别？

我刚开始接触 HSM 时也搞混过。有一次汇报，我把压力测试报告说成性能测试报告，被架构师当场纠正。从那以后，我逼自己把这两个概念彻底分清楚。

说白了，性能测试是个大框，压力测试是里面最狠的那一类。今天我们就从最基础的东西讲起。

先看一个对比表，这是我当年自己画在工位上的。

我习惯用一个比喻——性能测试是给车测百公里加速，压力测试是把车开到爆缸，看它爆在哪个点。对于 HSM，前者关注签名速度够不够快，后者关注在高并发下密钥会不会出错、会不会直接卡死。

做压力测试，你盯不住这几个指标就等于白做。我带过的团队里，最常见的问题就是“压了好多轮，但不知道看哪个数”。

QPS 是每秒查询数，TPS 是每秒事务数。对于 HSM 来说，本质是一样的——每秒能处理多少个安全操作。

我记得有一次在一个金融项目中，客户说他们的 HSM 需要支持 2000 TPS。我们按这个指标做压力测试，结果发现 HSM 在 1800 TPS 时就开始排队了。为什么会这样？因为客户指的 2000 TPS 是纯签名操作，而实际场景里混着解密和密钥生成，这些操作耗时差很多。

我的习惯：压测前先把操作的混合比例定死。比如 70% 签名、20% 解密、10% 密钥生成。这样测出来的 TPS 才靠谱。

延迟分两种：平均延迟和分位延迟（P99、P999）。

我见过有人只看平均延迟，觉得 5ms 很不错。但一查 P99，好家伙，500ms。这意味着每 100 个请求里有 1 个要等半秒。在高频交易场景里，这 1% 的慢请求可能就让订单超时了。

HSM 的延迟通常包括三部分：

前两部分是我们可以调优的，第三部分取决于 HSM 的硬件能力。你想想看，如果压测时发现延迟飙升，90% 是排队造成的。

避坑指南：我曾经因为没区分网络延迟和硬件计算延迟，把 HSM 的瓶颈误判成网络问题。结果折腾了三天网络配置，最后发现是 HSM 内部队列满了。建议在客户端和服务端同时打时间戳，算一下实际传输耗时。

吞吐量其实是 QPS / TPS 的另一种说法，但单位可以有变化。有时候以“字节/秒”计，比如 HSM 加密 1KB 的数据包和加密 1MB 的数据包，吞吐量数字差很多。

我个人习惯把吞吐量和延迟画在一张图上——随着并发数上升，吞吐量不再增长的那一点，就是 HSM 的真实极限。那个点通常比理论标称值低 20% 到 30%。

这里三种类型，是每个 HSM 压力测试项目必须覆盖的。我按执行顺序来说。

负载测试的目标是确认系统在预期负载下的表现。

怎么做？

我习惯把阶梯分成 5 档：20%、40%、60%、80%、100%。每档跑 5 分钟。这样能看出系统在哪个负载点开始抖动。

  重点：负载测试不是说“到了目标值就行”，要看曲线是否平滑。如果 80% 负载时延迟突然翻倍，说明系统内部有资源竞争，需要优化。

稳定性测试又叫长时间测试或耐力测试。很多 HSM 在短期压测里表现很好，跑上 48 小时就开始出问题。

我在一个项目中就遇到过——HSM 在前 6 小时表现完美，但在第 7 小时开始出现偶发的“密钥句柄泄露”。因为压测脚本没有及时释放密钥句柄，导致 HSM 内存慢慢被吃光。

稳定性测试的要点：

我的建议：稳定性测试最好凌晨开始跑，跑完刚好白天可以分析结果。如果白天跑，万一压崩了，影响业务就麻烦了。

峰值测试的目标是：在超出预期最大负载的情况下，系统会怎样？

压力测试里最痛的一种就是峰值测试。不是简单加一点，而是直接上 150%、200% 甚至 300% 的负载。

我记得有一次做 HSM 的峰值测试，目标负载是 2000 TPS，我们压到了 5000 TPS。结果 HSM 在 4300 TPS 时直接返回“服务不可用”。重启后检查日志——是硬件保护机制触发了，不是真正的故障。

这其实是个好结果。说明 HSM 有熔断保护，没让密钥状态出问题。

测试类型	负载	持续时间	核心关注点
负载测试	预期峰值	20~30 分钟	延迟与吞吐量曲线
稳定性测试	70%~80% 峰值	24~72 小时	资源泄漏、长时间性能衰减
峰值测试	150%~300% 峰值	5~15 分钟	崩溃点、恢复能力、数据完整性

  一句话总结：负载测试看“行不行”，稳定性测试看“久不久”，峰值测试看“烂不烂”。三件事做完，你才能说你对 HSM 的性能心中有数。

上面这张图是我每次给新人讲压力测试基础时都会用的。它把三个核心模块串在一起——你先搞清楚性能测试和压力测试的差异，再盯住三个关键指标，最后根据不同的测试类型去执行。少一环，测试结果就不完整。

嗯，这一章的基础概念就到这里。后面我们会拿着这些指标和类型，开始真正构造压测脚本。