压力测试核心指标：别被数字忽悠了

做压力测试，说白了就是给系统“找茬”。你得知道看哪些数据，才能判断它到底行不行。我见过不少团队，跑了一堆测试，最后拿出的报告全是数字，但没一个说到点子上。

这一章，咱们就把最关键的几个概念掰开揉碎。你把这些搞懂了，后面调优才有方向。

并发数：到底多少人同时在线？

并发数，指的是同一时刻，系统正在处理的请求数量。注意，不是“注册用户数”，也不是“每秒请求数”。

我遇到过有人把公司注册用户100万直接当成并发数来压测，结果机器直接崩了。你想想看，100万人怎么可能同时给你发请求？

HSM SDK的场景更特殊。HSM是硬件，它内部有并发通道限制。比如一个HSM只能同时处理32个加密请求，你压100个并发，其中68个就得排队。不是SDK不行，是硬件瓶颈到了。

吞吐量：单位时间能干多少活

吞吐量，指的是系统在单位时间内成功处理的请求数。常用单位是“请求/秒”或“操作/秒”。

我习惯把吞吐量看作“水管的流量”。管子粗，流过去的水就多。但水压不够（响应时间慢），流量也上不去。

记得有一次，客户抱怨他们的HSM性能不够。我一查，他们压测时用的全是1024位RSA密钥。换成2048位后，吞吐量直接腰斩。这不叫性能差，这叫用错场景测错了指标。

响应时间：点一下等多久

响应时间，就是从发出请求到收到完整响应之间的时间间隔。单位通常是毫秒。

正确的做法是看“百分位响应时间”：

• P50：一半请求比这个快。
• P95：95%的请求比这个快——这才是用户体验的底线。
• P99：1%的慢请求，通常需要重点排查。

HSM SDK的响应时间由三部分构成：网络传输 + SDK处理 + HSM执行。哪一块慢了，都能直接体现出来。

QPS 与 TPS：一个侧重请求，一个侧重事务

这两个概念容易混。我简单说一下：

• QPS（Query Per Second）：每秒查询数。侧重读操作，比如查一个证书状态。
• TPS（Transaction Per Second）：每秒事务数。一个事务可能包含多次请求，比如“登录->获取令牌->签名->退出”算一个完整事务。

对于HSM SDK，你用什么取决于业务场景：

资源利用率：别把硬件跑冒烟了

资源利用率，说的是CPU、内存、网络、磁盘I/O被用了多少。但HSM SDK特殊在——它依赖硬件安全模块，所以还得关注HSM本身的利用率。

我在项目中遇到过一件事。压测时CPU才跑30%，但HSM已经100%了。客户说“机器这么闲，为啥不继续加压？”我告诉他们：HSM是瓶颈。你再加压，请求都得排队，响应时间反而更差。

HSM的资源利用率通常要看：

• HSM内部通道占用：比如32通道用了30个，接近饱和。
• HSM内存/密钥槽占用：密钥加载太多，会拖慢查找速度。
• PCIe带宽占用：如果HSM是PCIe卡，数据吞吐量受总线限制。

它们之间的关系：一个综合公式

这几个指标不是孤立的。它们之间的关系，我习惯用一个公式来理解：

吞吐量 ≈ 并发数 / 平均响应时间

为什么是“≈”？因为系统有损耗，有排队，有锁竞争。你想想看，并发数增加一倍，响应时间往往会变长，所以吞吐量不会线性翻倍。

下面这张图，是我用来跟团队讲“压力测试核心指标关系”的，你拿去直接用：

综合示例：一个真实的压测复盘

我拿之前调一个PKCS#11 SDK的例子来说。客户要求：并发32，吞吐量不低于1000签名/秒，P95响应时间不超过100ms。

第一轮压测结果：

• 并发32，吞吐量只有650签名/秒。
• P95响应时间：180ms。
• HSM通道利用率：100%（32个通道全满）。
• SDK所在机器CPU：45%。

问题在哪？看资源利用率就明白了。HSM已经打满了，SDK和CPU都在等它。不是SDK慢，是HSM到了极限。

怎么解决？客户换了更高规格的HSM（支持64通道），再次压测：

你看，并发数和测试脚本完全没变，只是换了个更强的HSM，所有指标全达标了。这就是资源利用率的价值——帮你一眼锁定瓶颈在哪。

这几个概念是地基。下一层，我们要把这些数字变成可执行的测试场景。嗯，那都是后话了。