第4章：压测指标定义——TPS、响应时间、错误率、资源利用率
做性能测试，第一件要搞明白的事就是：到底看什么数据？
我见过不少团队，拿着压测报告一脸懵，数据一大堆，就是不知道哪些才是关键。说白了，PKI场景下的性能指标和其他系统不太一样，它跟安全、跟证书、跟密码运算绑定在一起，不能只看一个数。
这四大指标啊，我个人习惯把它们比作汽车的仪表盘：TPS是速度表，响应时间是刹车距离，错误率是故障灯，资源利用率是油温水温。任何一个表出问题，车都跑不稳。
4.1 TPS（每秒事务数）—— 整个系统的“肺活量”
含义
TPS全称是Transactions Per Second，翻译过来就是每秒能完成多少个业务事务。注意，这里说的是“事务”，不是“请求”。在PKI场景里，一个事务通常对应一个完整的密码操作，比如签发一张证书、验证一条CRL、做一次签名。
计算方法
最直接的算法：
TPS = 成功完成的事务总数 / 压测持续时间（秒）举个例子，你跑了60秒的压测，总共签发了18万张证书，那TPS就是180000 / 60 = 3000。简单吧？但实际操作时，我建议你取多个时间窗口的平均值，别只看最终结果。为什么？因为系统往往有波动，开头冲得高，后面可能掉下来。
| 计算方式 | 适用场景 | 注意点 |
|---|---|---|
| 平均TPS | 长时间压测（≥10分钟） | 平滑曲线，隐藏波峰波谷 |
| 峰值TPS | 秒杀、突发流量模拟 | 反映系统瞬时承受能力 |
| 滑动窗口TPS | 精细分析抖动 | 窗口大小选5秒或10秒为宜 |
PKI场景下的意义
PKI业务有个特点：每次证书操作都涉及非对称密码运算，比普通HTTP请求重得多。TPS高不代表好——我记得有个项目，客户吹嘘自家系统TPS能跑1万，我一测发现他用的全是1024位RSA，换成2048位RSA，直接掉到3500。你想想看，一个指标背后藏了多少细节。
重点纪要：TPS是性能的第一道门槛。但别只看峰值，要看“在满足响应时间和错误率的前提下”的可持续TPS。我习惯把这个叫“有效TPS”。
4.2 响应时间 —— 用户的真实等待感
含义
响应时间就是从一个请求发出去，到收到完整响应所花的时间。单位通常是毫秒。在PKI场景里，这可能是用户点一下“申请证书”到拿到证书文件的总时长。
计算方法
压测工具都会自动采集，但你要关心的是几个关键分位值：
- 平均响应时间：所有请求的平均值，容易被极端值拉偏。
- P95（95分位）：95%的请求都小于这个值，比平均值更靠谱。
- P99（99分位）：衡量最慢的那1%用户，适合做SLA。
- 最大响应时间：最慢的一次请求，通常不稳定，仅供参考。
PKI场景下的意义
我以前遇到过一个问题：系统TPS很高，但用户就是觉得卡。一查响应时间，P95是320ms，看起来没问题。但P99到了3.8秒。为什么？因为证书撤销列表（CRL）的查询峰值把某些请求堵死了。用户不会关心平均数，他只知道自己等了3秒多。
PKI业务里，密钥生成和证书签发是响应时间的大头。RSA密钥生成动辄几百毫秒，SM2会快一些，但如果你是软算法和硬件的混合部署，响应时间曲线可能会分叉——硬件模块处理快，软件模块排队慢。
避坑指南：我曾经踩过这个坑——只优化平均响应时间，忽略P99。结果P99比平均值高出一个数量级。从那以后，我在所有压测报告里都要求同时列出P50、P95和P99。
4.3 错误率 —— 系统的“诚实度”
含义
错误率是压测过程中失败的事务占总事务数的比例。什么算失败？HTTP 500算，超时也算，证书格式错误也算，签名验证失败更算。
计算方法
错误率 = （失败事务数 / 总事务数）× 100%通常要求错误率低于0.1%，甚至更严格。但PKI场景里，错误类型千差万别：
- 协议层错误：连接超时、TLS握手失败 —— 可能是并发太高了。
- 业务层错误：证书DN格式不对、私钥不匹配 —— 跟性能无关，但压测时会暴露。
- 算法层错误：签名验签失败、密钥生成异常 —— 可能是硬件密码模块的驱动问题。
PKI场景下的意义
错误率对PKI系统特别敏感。证书签错了，或者私钥生成过程中出了问题，用户拿到的就是一张废证书。不能安全使用的系统，性能再高也没用。
我碰到过一个案例：压测时错误率突然从0.01%飙到3%。排查发现是数据库连接池用完了，签发的证书写不进去。TPS没怎么掉，但错误率报警了。你看，只看TPS的话，根本发现不了这个隐患。
警告：压测中如果发现错误率上升，第一时间要看错误码分布。不要只看百分比。错误的类型决定了你要优化代码、扩容还是调参数。
4.4 资源利用率 —— 硬件的“疲劳度”
含义
资源利用率就是CPU、内存、磁盘I/O、网络等硬件资源被使用的情况。在PKI压测里，我最关心的是CPU和内存，因为密码运算是吃计算密集型的。
计算方法
工具直接采集即可：
| 资源类型 | 关键指标 | PKI场景中的常见瓶颈 |
|---|---|---|
| CPU | 使用率（%）、上下文切换 | 大数运算消耗CPU，RSA 4096位最明显 |
| 内存 | 使用率、GC频率 | 证书缓存、CRL List加载 |
| 磁盘I/O | IOPS、延迟 | 日志刷盘、证书数据库写入 |
| 网络 | 带宽、包量 | OCSP响应、CRL分发 |
PKI场景下的意义
资源利用率告诉你系统到底累不累。你想想看，TPS跑得再高，如果CPU已经99%了，那说明系统已经到了极限，再加压就要崩。反过来，如果TPS上不去但CPU才30%，那问题不在硬件，在别的层面。
我记得有一次调优，发现服务器CPU空闲，但TPS就是上不去。最后排查是线程池锁竞争导致任务都在排队。这就是资源利用率没体现出来的“隐性瓶颈”。所以，资源利用率要结合TPS和响应时间一起看，孤立的数据没有意义。
经验总结：我一般先看CPU是否打满（目标利用率在70%-80%为宜），再看内存是否泄漏（GC曲线平缓就是好现象）。如果出现CPU空闲但TPS低，八成是锁或者I/O阻塞。
这四个指标不是孤立的。你单看TPS，可能觉得系统性能不错；但加上响应时间和错误率，可能就发现质量有问题；再结合资源利用率，才能找到瓶颈到底在哪。