压测目标与性能指标定义

说实话，我见过不少团队拿到 SDK 就开始闷头跑压测。结果呢？跑了三天，数据一堆，一问「你们到底想测什么？」——答不上来。这是个很典型的坑。我个人习惯，压测之前必须先定目标，目标决定了你要盯哪些指标。

为什么要先定目标？

你想想看，PKI 证书 SDK 处理的业务场景差异很大。有的场景是批量签发，一次请求发几百张证书；有的是在线验证，毫秒级响应要求。如果不分场景一刀切，测出来的数据基本没用。

我建议分三步走：

1. 业务场景梳理 – 列出 SDK 实际会被调用的所有场景（签发、吊销、验证、更新）。
2. 压测目标定义 – 每个场景明确一个核心目标，比如「支持 1000 并发下，P99 响应时间 < 500ms」。
3. 指标维度选择 – 从目标倒推需要采集哪些性能指标。

核心性能指标清单

压测 PKI 证书 SDK，我一般只盯下面这 6 个指标，多了反而干扰判断。

指标之间的关联与权衡

这些指标不是孤立的。我常用一个简单的关系图来理解：并发数 ↑ → 响应时间 ↑ → TPS 可能先升后降。为什么会这样？因为当并发超过系统处理能力时，请求开始排队，响应时间急剧上升，TPS 反而可能下降。

举个例子，某个签名 SDK 在 200 并发时 TPS 是 800，响应时间平均 200ms。当我们把并发升到 400，TPS 只涨到 900，但响应时间飙到了 500ms。这时候再增加并发已经没有意义了。

如何根据业务场景设定指标阈值

不同场景下阈值差异很大。我整理了一个对照表，帮你快速定位。

避坑指南（我的血泪经验）

• 「TPS 高但响应时间慢」 – 这往往是因为请求被异步处理了，客户端发得快但实际后端排大队。一定要加端到端延迟监控。
• 「并发数一直上不去」 – 检查客户端是否有限流、连接池是否太小、SDK 内部是否有锁竞争。我曾经遇到过连接池默认的 10 个连接限制了并发，调大后 TPS 直接翻倍。
• 「错误率突然跳高又恢复」 – 大概率是 GC 导致 STW（Stop The World）将请求阻塞了，超时后重试造成雪崩。解决办法：减少 GC 频率、增加超时缓冲。
• 「指标看起来都正常但用户体验差」 – 可能是尾延迟问题，平均值漂亮但个别请求卡顿几秒。必须关注 P99.9 甚至 P99.99。

我个人习惯，每次压测开始前先画一张指标关系图，把目标、指标、环境、阈值串起来。下面这张图就是我最常用的框架：

这张图看起来简单，但每次压测前对着它走一遍，基本不会漏掉关键点。说白了，压测不是造数据，而是验证你对业务和系统的理解是否正确。