性能调优指标体系：延迟、吞吐、CPU、内存

性能调优这事儿，说白了就是找到系统的瓶颈在哪。我刚开始接触TLS时，总以为把SDK接上就完事了。结果生产环境一跑，延迟翻了好几倍，CPU直接飙到90%。嗯，从那以后我才明白——指标不会骗人，但前提是你得知道看什么指标。

我个人习惯把调优指标分成四类：延迟、吞吐、CPU、内存。这四个维度互相影响，得一起看。你想想看，只优化延迟，可能让CPU暴涨；只抠内存，吞吐可能直接掉下去。

延迟：用户感知的第一道门槛

延迟就是用户发出请求到收到响应的时间。TLS接入后，延迟增长主要来自握手阶段。

我在项目中遇到过握手阶段延迟占整个连接60%以上的情况。特别是首次连接，需要做证书验证、密钥协商，这个开销跑不掉。

那么延迟怎么测？说白了就是看两个地方：

• P50/P99延迟：P50代表中位数，P99代表最慢的那1%请求
• 握手耗时分布：用工具抓包，看TLS握手具体花了多长时间

我建议优先优化P99延迟。因为P50好看不代表系统真的稳，最慢的那批用户才是最需要关注的。

吞吐：系统能扛多少并发

吞吐反映的是系统单位时间能处理多少请求。TLS接入后，吞吐通常会下降。为什么？因为有加解密这个计算瓶颈。

我记得有个项目，裸连接能扛1万QPS，加上TLS直接降到3000。这个降幅就有点离谱了。后来一排查，发现是证书链太长，验证时间占用过多。

场景	吞吐（QPS）	主要瓶颈
裸连接	10000	网卡带宽
TLS短连接	3000	握手开销
TLS长连接（会话复用）	8500	加解密运算

你看这个表就明白了——会话复用对吞吐的恢复效果非常明显。所以我的建议是：能复用就别新建连接。

CPU：别让你的服务器变成取暖器

TLS最耗CPU的地方就是加解密。你知道哪个环节最耗CPU吗？不是数据传输，是握手阶段的密钥协商。

如果你发现CPU占用率居高不下，先判断是业务逻辑高，还是TLS加解密高。用perf top或者top -H一看便知。

我个人习惯在调优初期先保证CPU使用率不超过70%。超过这个阈值，系统响应就会开始抖动。你想想看，CPU到了90%，新请求排队等着，延迟能不涨吗？

内存：容易被忽略的隐性杀手

内存问题往往不是突然爆炸的，而是慢慢累积的。TLS SDK接入后，内存消耗主要来自这几个地方：

• 连接对象：每个TLS连接都有一个SSL上下文对象，内存占用在几KB到几十KB
• 会话缓存：session ticket和session ID的存储
• 证书存储：根证书、中间证书的加载

我遇到过最夸张的情况——某团队开了10万个长连接，每个连接都保存了完整的证书链。结果内存直接爆了，OOM killer开始疯狂杀进程。

内存优化的核心思路就四个字：能省则省。能复用的对象不复用，该回收的内存不回收，早晚会出事。

最后，我把这四类指标的关系整理成一张图，方便你理解它们之间的联动。