第 3 章：压力测试理论基础——性能指标、测试类型与方法论
嗯，咱们直接进入正题。压力测试不是随便把请求怼上去看系统挂不挂，你得先搞清楚三个维度：用什么量、测什么模式、按什么顺序跑。这三样清楚了，你的测试才有根。
3.1 核心性能指标：TPS、延迟、并发
我个人习惯把性能指标分成三大类——吞吐、响应和并发。记住一个原则：单指标不构成优化依据，必须三指标联动看。
3.1.1 TPS（Transactions Per Second）
TPS 是系统每秒能处理的事务数。在 HSM SDK 场景里，一个事务就是一次完整的加解密调用，从发送命令到收到响应。
- 为什么重要？ 直接反映硬件密码模块的处理上限。
- 怎么测？ 用恒定并发数逐步加压，观察 TPS 曲线。
- 我踩过的坑： 有一次测 L 型号的 HSM，TPS 跑到 850 左右突然掉到 500，我以为芯片有 bug。后来发现是 SDK 线程池默认连接数只有 10，瓶颈根本不在设备上。
3.1.2 延迟（Latency）
延迟分三种：平均延迟、P99 延迟、最大延迟。我建议重点关注 P99，因为平均延迟容易掩盖尾部长尾。
| 延迟类型 | 定义 | HSM 场景典型值 |
|---|---|---|
| 平均延迟（Avg） | 所有请求耗时均值 | 2~5 ms |
| P99 延迟 | 99% 请求在此值以下 | 5~10 ms |
| 最大延迟（Max） | 单次最慢请求 | 可超 100 ms（需排查） |
实战小贴士： 我习惯在压测脚本里同时记录发送时间戳和接收时间戳，然后额外打印每 1000 个请求的延迟分布。这样能快速判断 HSM 是否出现了“间歇性脑筋急转弯”——比如忽然有一两个请求卡了 200ms。
3.1.3 并发数（Concurrency）
并发数是指同一时刻正在处理请求的数量。关键关系：TPS = 并发数 / 平均响应时间。如果并发数提升但 TPS 不涨，说明系统已经进入瓶颈区。
- 过低的并发： 资源闲置，测不出上限。
- 过高的并发： 队列溢出，延迟爆炸。
- 建议做法： 从 1 个并发开始，每次翻倍，直到 TPS 停止增长。
注意： 千万不要在 HSM 上跑“无限并发”脚本。我曾经看到有人用几百个线程同时发加解密请求，结果 HSM 内部队列被撑爆，直接返回硬件错误码。HSM 不是普通 Web 服务器，它有物理并发限制。
3.2 测试类型：负载测试、压力测试、稳定性测试
三种测试目的不同，方法也不同。很多人把“压力测试”当成统称，其实下面要细分。
3.2.1 负载测试（Load Testing）
说白了就是“正常运行时能撑住多少人？”用预期的业务并发数（比如 50、100、200）持续跑一段时间，看系统是否稳定。
- 目标：验证系统在预期负载下的表现。
- 关注指标：TPS 是否达标、P99 延迟是否在 SLA 内。
- 案例：某支付系统要求 HSM 签名操作在 50 并发下 TPS ≥ 2000，P99 ≤ 5ms。负载测试就是验证这个。
3.2.2 压力测试（Stress Testing）
压力测试是要找到系统的极限和崩溃点。逐步增加并发数，直到系统性能出现拐点甚至崩溃。我一般把这个测试叫做“探顶测试”。
- 目标：找到系统能承受的最大并发数和 TPS 上限。
- 方法：阶梯式加压，每次保持 30 秒，记录拐点。
- 特别注意：HSM 压力测试中，一旦出现硬件错误码或连接断开，要立即停止并记录当前负载。
经验： 我记得有一次在某金融客户的 HSM 集群上做压力测试，到 300 并发时 TPS 掉了一半，但设备还没报错。后来查日志发现是 SDK 的内部线程竞争锁导致。所以压力测试不仅要测设备，更要测 SDK 层。
3.2.3 稳定性测试（Stability / Soak Testing）
长跑测试，通常是 4~8 小时甚至 24 小时。目的是发现内存泄漏、连接泄漏、资源耗尽等“慢性病”。
- 负载水平：使用业务峰值并发的 80% 左右。
- 监控重点：内存占用、连接数、TPS 波动。
- 我的建议：稳定性测试一定要跑过夜，第二天早上看监控图。
3.3 方法论：如何设计压力测试场景
光知道指标和类型还不够，你得有一套流程。我自己常用的步骤，这里拆给你看。
- 确定测试目标和基准线 - 先问业务：SLA 的 TPS 和 P99 是多少？然后拿一个已知稳定的版本跑基线。
- 设计场景矩阵 - 把测试类型、并发阶梯、持续时间组合成表格，比如：负载测试（并发 50/100/200，各 5 分钟）、压力测试（并发 50→800，步长 50，每步 30 秒）、稳定性测试（并发 200，持续 8 小时）。
- 准备监控和日志 - 至少采集：HSM 设备 CPU/内存、网络吞吐、SDK 线程状态、错误日志。我习惯在压测脚本里额外打印每次请求的耗时和返回值。
- 执行并记录拐点 - 严格按照场景运行，注意观察曲线突变。比如 TPS 突然下降或延迟突然上升，就是拐点。
- 分析瓶颈并回放 - 记录拐点时的资源状况，然后复位系统，用相同负载复现验证。
关键警告： 压力测试前必须确认 HSM 固件版本和 SDK 版本匹配。我有一次没核对版本，跑压力测试时签名耗时从 2ms 涨到 20ms，查了两天才发现是 SDK 与固件不兼容导致的代理模式回退。
3.4 关于方法论的一点个人补充
我见过不少团队，上来就用 Jmeter 设个 1000 线程开始跑，毫无章法。说实话，这样跑出来的数据只能叫“压力曲线”，不能叫“测试结论”。真正的方法论，要求你每次只改变一个变量，其他条件保持不变。
- 先跑一次空载，确认系统正常。
- 然后跑负载测试，确认基线。
- 再跑压力测试，找上限。
- 最后跑稳定性，验证长期可靠性。
每一步产生的数据都要录进表格。我自己的经验是：记录比分析更重要。因为很多问题是在回看数据时发现的，比如某次压力测试后，你会看到 TPS 曲线在 350 并发处有一个小凹陷，第二次测试同样的凹陷还出现，那可能就是共振问题了。
最终记住： 压力测试不是拿系统去死磕，而是用科学方法暴露系统的真实边界。你知道了边界，才能设计出可靠的降级和限流策略。