第三章 关键性能指标：延迟、吞吐量、并发能力
性能调优不能靠感觉。必须用量化的指标说话。我个人习惯先盯三个数字：延迟、吞吐量、并发能力。这三者互相关联，又互相制约。搞清楚了它们，调优才有方向。
3.1 延迟（Latency）—— 每一毫秒都算数
延迟就是一次密钥操作从发出到完成的时间。说白了，用户发出一个签名请求，到拿到签名结果，中间等了多少毫秒。
我在项目中遇到过一个大坑：某银行密钥服务日常均延迟只有5ms，但每隔几分钟就会跳出一次200ms的尖刺。业务方投诉“系统不稳定”。后来发现是GC停顿导致的——这个后面章节会细讲。
延迟的度量方式：| 指标 | 含义 | 典型参考值 |
|---|---|---|
| 平均延迟 | 一段时间内所有请求延迟的平均值 | API签名 < 10ms |
| P99延迟 | 99%的请求都在这个延迟以下 | < 50ms |
| 最大延迟 | 最慢的一次请求时间 | 尽量 < 200ms |
注意：只看平均延迟会掩盖问题。我曾经遇到过平均延迟8ms很好看，但P99却高达500ms的情况。一定要同时监控P99甚至P999。
延迟的主要瓶颈在哪？
- CPU计算：非对称密钥生成、签名验签都是CPU密集型操作。
- IO等待：从HSM（硬件安全模块）读取密钥、数据库查询证书链。
- 锁竞争：多个线程同时操作同一个HSM会话时，锁会导致排队。
3.2 吞吐量（Throughput）—— 每秒能扛多少请求
吞吐量衡量系统在单位时间内能处理多少密钥操作。常用单位是TPS（Transactions Per Second）或QPS（Queries Per Second）。
你想想看，一个密钥服务中心如果每秒只能处理100次签名，但业务流量是200 TPS，系统就会积压。积压反过来又推高延迟，恶性循环。
吞吐量的计算公式：吞吐量（TPS） = 并发线程数 / 平均响应时间（秒）举个例子：假设并发线程数开到64，平均响应时间是10ms（即0.01秒），理论最大吞吐量 = 64 / 0.01 = 6400 TPS。但实际中受限于CPU核数、HSM硬件能力，往往打不到这个数。
个人经验：压测吞吐量时一定要先摸清HSM的硬件上限。我曾经在一款老旧HSM上跑压测，单台HSM的签名吞吐最多只有3000 TPS，再往上加线程也没用——硬件本身成了瓶颈。
- 密钥算法类型（RSA 2048 vs ECDSA，RSA明显更慢）
- 连接池大小（HSM连接池不足会限制并发）
- 业务模型（是纯签名，还是签名+验签混合？验签通常比签名快）
3.3 并发能力（Concurrency）—— 同时能处理多少人
并发能力指系统能够同时支撑多少条活跃连接或正在处理的请求。它不等同于吞吐量。举个例子：系统能同时维持1000个TCP连接，但每个连接每秒只发一个请求，总吞吐量也就是1000 TPS。但如果每个连接发10个请求，吞吐量就上去了。
并发能力的核心资源是线程和连接。密钥服务通常是IO密集型+CPU密集型混合。我曾经调过一个项目，初始配置线程池只有核心线程数4个，并发压到50时延迟飙升。后来把线程池调整到核心16、最大64，配合合理的队列大小，并发能力就上来了。
并发能力的关键参数：| 参数 | 建议范围 | 说明 |
|---|---|---|
| 核心线程数 | CPU核数 × 2 | 避免过多线程上下文切换 |
| 最大线程数 | CPU核数 × 4 或更高 | 允许突发流量 |
| 队列长度 | 100 ~ 1000 | 太长会导致超时 |
| HSM连接池 | 10 ~ 50 | 视HSM支持的最大会话数 |
这三个指标的关系：并发能力是底座，它决定了你能达到的理论吞吐上限；延迟是质量，低延迟才能撑起高吞吐。牺牲并发换延迟，或牺牲延迟换并发，都是调优中常见的权衡。
3.4 如何衡量这三个指标？
光有概念不够，你还得知道怎么测。我习惯用以下工具和脚本：
- wrk / ab：压测HTTP接口的延迟和吞吐量。
- JMeter：模拟复杂的并发场景，比如混合签名和验签。
- Prometheus + Grafana：生产环境持续监控P99延迟和TPS趋势。
# 压测密钥签名接口：30秒，32个并发连接
wrk -t4 -c32 -d30s --latency https://keyservice/sign
# 输出会显示：
# Latency Distribution (ms)
# 50% 8.12
# 75% 10.45
# 99% 45.67
# Requests/sec: 3456.78看结果时我重点关注P99延迟和Requests/sec。如果P99超过50ms，说明系统有瓶颈。如果Requests/sec低于预期，检查CPU使用率和HSM连接数。
3.5 三种指标的权衡策略
你不可能同时把三个指标都做到极致。为什么？因为资源是有限的。我总结了一个常见场景的调优优先级：
| 业务场景 | 首要指标 | 次要指标 | 调优方向 |
|---|---|---|---|
| 实时交易签名 | 延迟 | 吞吐量 | 减少线程切换、使用异步IO、缓存密钥 |
| 批量文档签名 | 吞吐量 | 延迟 | 增加并发数、分批处理、HSM流水线 |
| IoT设备认证 | 并发能力 | 延迟 | 扩大连接池、无状态设计、读写分离 |
分享一个真实案例：我之前帮一个金融科技公司优化密钥服务，他们要求P99延迟 < 20ms。我先把线程池从固定大小改成动态调整，然后引入HSM的会话复用。最终P99从48ms降到了14ms，但吞吐量也降了一点。客户接受——因为延迟是他们的生命线。
3.6 避坑指南
别把指标测错了：
- 压测一定要用和线上相同的密钥算法和密钥长度。RSA 4096和RSA 2048的延迟差了好几个数量级。
- 并发数不是越大越好。我曾经把并发线程从64加到128，结果CPU上下文切换暴增，吞吐量反而下降了。
- 记得加超时保护。没有超时，一旦HSM卡住，所有线程都会堆积阻塞。