3. HSM性能指标：吞吐量、延迟、并发连接数、密钥加载速度、批处理能力
搞性能调优，你得先知道什么才是「快」。很多人上来就问这个 HSM 能跑多少 TPS，好像只要 TPS 高就万事大吉了。其实不是这么回事。我个人习惯把性能拆成五个维度来看：吞吐量、延迟、并发连接数、密钥加载速度、批处理能力。
咱们一个个来说。
3.1 吞吐量（TPS）
TPS，全称是 Transactions Per Second，每秒能处理多少次签名或验签。这是大家最熟悉的指标。
我当年刚上手的时候，也以为 TPS 只跟 HSM 硬件本身有关。后来在项目中踩过坑才发现——网络开销占了大头。你想想看，一次签名请求发出去，HSM 算完再回给你，光在网络上就跑了几毫秒。HSM 本身可能 1 毫秒就搞定了。那个「几毫秒」的传输时间，恰恰是瓶颈。
避坑指南：我曾经遇到过一个案例，客户说买的是高配 HSM，但生产环境 TPS 就是上不去。最后排查发现，应用服务器和 HSM 隔着三层交换机，网络延迟多了 3 毫秒。就这么 3 毫秒，TPS 直接掉了一半。所以 TPS 的调优，一定要看端到端的链路，别只看 HSM 的裸能力。
还有一点，签名和验签的 TPS 不是一回事。签名通常比验签重得多，尤其像 RSA 2048 这类算法。我建议你在压测的时候，分开记录「签名 TPS」和「验签 TPS」。不然你混在一起，出了问题你都不知道是算法慢还是网络慢。
3.2 延迟（毫秒级）
延迟，就是指从发出请求到收到结果，所花的时间。以毫秒计。
我见过很多工程师只看 TPS，不看延迟。说白了，TPS 是批量的能力，延迟是单笔的质量。有些场景，比如支付签名，延迟超过 20 毫秒客户就会投诉。TP99 延迟更重要。
我个人习惯用百分位延迟来衡量。举个例：
某HSM签名测试结果（RSA 2048，10000次）：
平均延迟：8.5 ms
P50 延迟：6.2 ms
P99 延迟：22.1 ms
P999 延迟：95.4 ms
为什么 P99 和平均差这么多？我在项目中遇到过，偶尔的慢请求主要是因为 HSM 连接的线程竞争。HSM 底层硬件多通道并行执行，但如果应用层的请求调度不好，就会出现「九十九笔快，一笔慢」的情况。
怎么治？我建议你在连接池里增加与 HSM 的物理会话数，别让所有请求挤在同一根管子里。
3.3 并发连接数
并发连接数，就是 HSM 同时能处理多少条会话连接。这个指标很容易被人忽略。你想想看，就算你 HSM 的 TPS 是 10000，但并发连接数只有 100，那也没用。因为每个连接只能串行发请求。
我记得有个客户，用的是一台老款的 HSM，并发限制只有 50。他们的业务量一上来，请求就排队，延迟直接飙升到 200 毫秒。后来换了一台支持 500 并发的新款，延迟立马降到 10 毫秒以内。
| HSM 型号 | 最大并发连接数 | 实测 TPS（RSA 2048 签名） |
|---|---|---|
| 入门级 | 50 | 500 |
| 中端 | 200 | 3000 |
| 企业级 | 1000 | 12000 |
调优的时候，你需要注意连接池的大小。不是越大越好。我在项目里试过，连接数超过 HSM 的硬件上限，反而会因为握手和上下文切换让性能下降。最佳值通常是在 HSM 文档标称的 70%-80% 左右。
3.4 密钥加载速度
密钥加载速度，说白了就是你把密钥从安全存储区导入到 HSM 工作内存，需要多长时间。这个指标在「冷启动」的时候特别重要。你比如说，重启 HSM 或者扩容新节点的时候，几百个密钥要加载，加载慢的话，业务就得等着。
我遇过一个尴尬的场面——新节点上线，密钥加载花了 15 分钟。结果那 15 分钟内，所有签名请求都超时。事后我查了一下，原因在于密钥是用单一线程逐个加载的。后来改成并行加载，速度提升了 4 倍。
调优小贴士：很多 HSMs 都支持密钥的批量导入。我个人习惯在做运维脚本的时候，直接用 API 批量加载，而不是一个个循环调用。另外，密钥的索引表做得好的话，也能减少查找时间，间接提升加载速度。
还有一个点：密钥的存储格式。比如用 PKCS#12 还是纯私钥文件，解析的时间不一样。我建议在性能压测时，把密钥加载速度也测一下，尤其是在灾备切换的场景下。
3.5 批处理能力
批处理能力，是很多人的盲区。它指的是 HSM 一次能处理多少条独立的签名或验签请求。很多 HSM 支持写一个批量请求，里面包含 100 条数据，然后一次性返回结果。
你想想看，单独发 100 次请求，一来一回网络开销就占满了。但如果用批处理，只发一次请求，HSM 内部用硬件并行算，很快就能出来。效果非常显著。
我自己实测过一组数据：
- 单笔签名：TPS 2000
- 批量 10 笔签名：TPS 12000（等效）
- 批量 50 笔签名：TPS 25000（等效）
当然，并不是批次越大越好。你想想，如果一批里有 50 个签名请求，其中一个出错了，那整批都要回滚。所以在实际业务中，我建议你用中等大小的批次，比如 10-20 笔，兼顾吞吐和容错。
核心观点：批处理能力是连接「密钥加载速度」和「吞吐量」的桥梁。如果你的业务场景允许攒一批请求再发，那性能会成倍增长。这一点在支付、证书签发等大并发场景下格外重要。
好了，到这五个指标都说完了。它们之间不是孤立的，而是互相影响的。为了让你更直观地理解，我给你画了一张结构图。
从图上你可以看到，这五个指标不是孤立存在的。比如说，并发连接数太低，延迟就会高，吞吐量也会被锁死；批处理能力好，又能反过来提升有效 TPS；密钥加载速度慢的话，扩容时就白搭了。所以你不能只盯着一个指标搞优化。
我建议你每次调优的时候，把这五个指标都记录下来，形成一个基线。然后改一个参数，再测一次，看看哪些变了哪些没变。只有这样，你才能真正理解你的 HSM 到底强在哪里、弱在哪里。