📚 课程目录第4章密钥服务性能指标定义

4. 密钥服务性能指标定义

做性能调优，第一件事不是上来就改参数，而是先搞清楚——你到底要优化什么？

我在项目里见过不少同事，一遇到慢就加线程池，一卡就提超时。结果呢？往往越调越糟。你想想看，连当前系统的瓶颈在哪都不知道，调优就是瞎蒙。

这一章，咱们就把密钥服务的性能指标一次说清楚。说白了，指标就是你的坐标。有了坐标，你才知道自己在哪，目标在哪。

我个人习惯把指标分成四大类。这张表格可以当你的速查手册。

我的一点经验：

很多团队只盯着QPS，觉得高了就行。但我曾经排查过一个案子，QPS很高，成功率掉了不少——嗯，你会发现业务方其实更在意成功率。指标要成体系，单看一个是会出事的。

QPS（Queries Per Second）是密钥服务最直观的指标。它直接决定了你的系统能扛住多大流量。

怎么测？其实很简单：固定并发数，压一段时间，看单位时间内的处理量。

# 示例：用openssl speed粗略测试本地签名性能
openssl speed ecdsa

但这个指标有个大坑。你往上加并发，QPS一开始会涨，涨到某个点突然就不动了，甚至会掉。为什么会这样？因为系统已经饱和了。这个拐点，就是你服务的“吞吐天花板”。

注意：

不要太相信厂商给的“最大QPS”数值。他们用的环境（硬件、网络、数据包大小）跟你不一样。我建议，拿到设备后自己压一遍，拿到第一手数据才算数。

举个例子。你在手机上点一下转账，等3秒才弹“成功”。你受得了吗？

延迟就是请求发出去到拿回结果的时间差。它通常包括：

这里我建议关注两个值：平均延迟和P99延迟。平均延迟能帮你判断整体体验，P99延迟则告诉你最差的那1%用户有多慢。

小技巧：

我曾经调过一个支付系统，P99延迟一直超标。后来发现，是某台机器的网卡中断分配不均，导致几个请求被卡了很长一段时间。换个irqbalance配置就解决了一大半。

这个指标其实不复杂。成功数除以总请求数，就是成功率。

但为什么我要单独拿出来说？因为很多人只看QPS和延迟，忽略它。我遇到过不少案例：“系统跑得挺快啊，但报错怎么这么多？”

常见失败原因：

正常线上服务的成功率，我一般要求99.9%以上。低于这个数，不用想了——先查失败日志，找到根因再说。

说白了，你性能再好，如果一台机器只能扛100QPS，另一台能扛5000QPS，那架构和成本的差距就出来了。

常用资源指标：

我的建议：

不要等到线上出问题了才看资源。平时压测时，就把CPU、内存、网络一起录下来。然后用单位资源能处理的QPS（比如每%CPU对应的QPS）来横向对比调优前后是否真的变好了。

你可能已经发现了，这些指标不是孤立的。它们相互影响。

下面这张图是我自己总结出的性能指标影响关系。你可以把它当成调优时的路线图。

举个例子：

你为了提升QPS，增加了并发数。起初有效，但接着CPU就满了。CPU满了以后，请求开始排队，延迟飙升。延迟一高，很多请求在客户端就超时了，最终成功率也下来了。你看，调一个点，全链路的指标都在动。

知道指标有什么用？用它们来定位瓶颈。

这个顺序，我自己在项目中用过很多次。按这个路径走，很少会跑偏。

避坑指南：

我曾经在没有看成功率的情况下，调了一个HSM的并发参数。结果QPS上来了20%，但成功率掉了5%。后来一查，是因为并发太高，后台HSM设备处理不过来开始丢包了。嗯，指标不看全，就容易白干。