3. 性能指标定义：TPS、延迟、吞吐量归纳总结
做性能调优和压力测试，第一步是搞清楚要测什么。你想想看，连指标都不统一，调优就成了各说各话。我自己带团队时，经常发现开发、测试、运维对同一个接口的「快」理解完全不一样。所以今天咱就把TPS、延迟、吞吐量这三个核心指标掰开揉碎了讲清楚。
3.1 TPS：每秒事务数
TPS（Transactions Per Second）是HSM SDK最直观的性能标尺。它告诉你：在单位时间内，系统能完整处理多少个“事务”。这里的事务指一个完整的密码学操作——比如生成一个密钥、签名一条数据、或者解密一段密文。
我在项目中遇到过一种典型误解：有人把API调用次数当成了TPS。其实HSM SDK里一次签名可能要调用2~3次底层硬件指令，但对外只算一个事务。所以定义事务边界很重要。
| 场景 | 事务定义 | 典型TPS范围（测试环境） |
|---|---|---|
| 对称加密 | 一次 AES 加密调用完成并返回结果 | 1000 ~ 5000 |
| 非对称签名 | 一次 ECDSA 签名计算 + 返回签名值 | 200 ~ 800 |
| 密钥生成 | 从请求生成到密钥句柄可用 | 100 ~ 300 |
| 批量签名 | 一批10笔事务打包后整体返回 | 1500 ~ 6000 |
3.2 延迟：每次操作花多久
延迟就是“等多久”。对HSM SDK来说，延迟分为网络延迟、硬件排队延迟、以及HSM卡内部计算延迟。我们压力测试时最关心的是平均延迟和P99延迟。
有什么区别？举个例子：你测了1000次签名，平均延迟是5ms，但最慢的那10次用了50ms。用户感受到的「卡顿」往往来自那1%的慢请求。我自己的经验是：只要P99延迟不超过平均延迟的3倍，就算健康。
3.3 吞吐量：系统总处理能力
吞吐量（Throughput）是TPS和延迟的乘积变体。它表示单位时间内系统能“消化”的总数据量。比如HSM SDK对文件加解密，你可能用MB/s来衡量。
吞吐量和TPS并不是线性关系。当数据块变大时，单个事务的处理时间增加，TPS会下降，但吞吐量可能反而上升——直到达到硬件瓶颈。下面这张表格能帮你快速理解三者的关系：
| 指标 | 单位 | 关注点 | 典型测量方法 |
|---|---|---|---|
| TPS | 事务/秒 | 并发处理能力 | 单位时间内完成的事务数 |
| 延迟 | 毫秒（ms） | 单次操作响应速度 | 从请求发出到收到响应的时间 |
| 吞吐量 | MB/s 或 操作/s | 系统总处理容量 | 总数据量 ÷ 总耗时 |
3.4 三者之间的关系——一张图看懂
为了方便记忆，我画了一张关系图。你能看到TPS、延迟、吞吐量是一个“不可能三角”——优化其中一个，另外两个往往会跟着变。
3.5 实际压测时如何选指标
老实说，很多人一上来就盯着TPS看。但我觉得，应该根据业务目标来决定优先级：
- 业务场景1：高频交易 —— 比如支付签名。TPS 是第一优先级，延迟只要不超过业务SLA就行。
- 业务场景2：批量数据处理 —— 比如加密大文件。吞吐量是重点，TPS反而可以低一点。
- 业务场景3：实时响应 —— 比如HSM远程调用。延迟最重要，特别是P99。
3.6 最佳实践：用表格做性能基线
我个人的习惯是，在压力测试前先定义好指标基线。下面是一个通用模板，你可以直接参考：
| 指标名称 | 目标值 | 预警阈值 | 测试工具 |
|---|---|---|---|
| TPS（签名） | ≥ 500 | < 300 | 自定义压测客户端 |
| 平均延迟（加密） | ≤ 8ms | > 15ms | JMeter + HSM插件 |
| P99延迟（解密） | ≤ 20ms | > 50ms | wrk + 自定义脚本 |
| 吞吐量（大文件加密） | ≥ 80 MB/s | < 40 MB/s | iperf + openssl |
好了，关于三个核心指标的定义和关系，就说这么多。记住一点：指标是死的，场景是活的。你需要根据自己业务的实际负载特征，灵活调整测试侧重点。别被数字骗了，也别忽略任何一张图——回头再看一遍上面的SVG关系图，你会有更深的理解。