性能基准指标与测量方法：QPS、TPS、P95/P99延迟、打点与采样
在做性能调优之前，如果连“跑得快不快”都说不清楚，那调优就是瞎忙活。这一章我不打算堆概念，而是聊聊我这么多年摸爬滚打下来，到底哪些指标真正能救命，又该怎么拿到这些数据。
为什么指标先行？
说白了，没有基准，就没有优化。你连起点都站不住，怎么知道终点在哪儿？我在项目里踩过一个坑：信心满满上线了一版优化过的PKI SDK，结果业务方反馈“比以前还慢”。最后定位发现，优化确实让签名快了，但内存占用飙了一倍，GC频繁触发，整吞吐反而降了。
这就是典型的“局部优化，全局崩盘”。你只有把所有关键指标都盯死了，才能避免这种翻车。
QPS 与 TPS：靠不靠谱要看场景
这两个概念我见过很多朋友搞混。QPS是针对单个请求或查询，TPS则是完整事务。在PKI场景里，一个证书签名事务可能包含多个步骤：验证签名请求、构造证书、回调通知。这时候QPS只能反应某个步骤的速率，TPS才能体现端到端的处理能力。
我的建议：如果是压测完整的PKI接口，盯住TPS就够了。你想想看，业务只关心“你一分钟能给我签多少个证书”，没人关心你内部某一步QPS有多高。
| 指标 | 定义 | PKI场景典型用法 |
|---|---|---|
| QPS | 每秒钟请求数 | 验证OCSP状态、查询CRL列表 |
| TPS | 每秒钟事务数 | 完整证书签发、吊销列 |
P95/P99 延迟：别被平均值骗了
很多人只看平均延迟。我跟你说，这是大忌。平均延迟会掩盖问题：90%的请求10ms搞定，10%的请求卡了10秒，一平均，变成1秒，好像还可以？其实用户体验已经炸了。
P99延迟的意思，就是排在前1%最慢的请求的延迟值。我们一般把这个叫做“长尾延迟”。
记得有一次，我们在证书签名SDK里发现了隐蔽的锁竞争。正常情况下P99延迟是50ms，但某几个线程因为等待锁释放，硬生生撑到了800ms。如果没有P99指标，这种问题根本不会被发现。
// 计算P99延迟的伪代码示例
sorted_latencies = sort(all_request_latencies)
n = len(sorted_latencies)
p99_index = int(n * 0.99) - 1
p99_latency = sorted_latencies[p99_index]
print(f"P99延迟: {p99_latency}ms")
资源开销：CPU、内存、网络一个不能少
- CPU：关注的是
用户态/内核态分布。PKI签名计算是纯CPU密集，一看用户态居高不下，说明运算量上来了。如果内核态也高，那多半是锁、系统调用在拖后腿。 - 内存：不只是看堆内存占用，更要看垃圾回收频率和老年代增长速率。我们曾经遇到一个内存泄漏，就是通过观察老年代每轮GC后仍然增长发现的。
- 网络：对于SDK来说，网络开销通常是调用方的问题。但如果SDK内部有状态同步、CRL下载之类操作，就要看连接复用率和带宽使用率了。
打点与采样：怎么做才不拖累性能
你想想看，为了测量性能，你往代码里插了一堆打点逻辑，结果打点本身让系统变慢了——这不就本末倒置了吗？
我常用的原则是：线上采样，线下全量。也就是说，影子环境压测时开启全量日志和全量打点来排查问题；线上则只启动latency采样（比如每100个请求采样1个），同时固定采集几个计数器（如总请求数、错误数）。
具体怎么做？我分享一套我自己的套路：
- 在关键路径入口和出口各打一个时间戳。
- 把耗时记录到一个本地环形缓冲区（而不是直接打印日志）。
- 缓冲区满后，做一个滑动窗口，采样最近N条记录做P99计算。
- 最后只把缩窄后的P99、P50、QPS这几个聚合值上报。
new HashMap，导致压测结果里30%的延迟都是打点带来的。后来改用预分配数组加原子计数器，才得到干净的数据。
实操流程：跑一次完整的基准测试
我把基准测量的全流程总结成一张图，方便你参考。
你按这个流程走一遍，基本就能拿到一套可信的基准数据了。记住一句话：性能调优，数据先行。没有指标，谈何优化？