基准测试方法论：性能指标定义与测试环境搭建

做性能测试，说白了就是给系统「称体重、量血压」。你得先知道秤准不准，血压计有没有校准。我见过太多团队，上来就压测，结果数据自相矛盾——TPS 忽高忽低，延迟曲线像过山车。为什么？指标没定义清楚，环境没搭对。

这一章，我们就聊聊怎么把这两件事做扎实。

性能指标：到底该看什么

签名验签的性能测试，核心指标就三个：TPS、延迟、CPU 占用。但每个指标背后都有坑。

TPS（每秒事务数）

TPS 是最直观的吞吐量指标。它表示系统每秒能处理多少个签名或验签请求。

我个人习惯把 TPS 拆成两步看：

• 理论峰值：在理想条件下（无网络抖动、无资源争抢），单机单核能跑多少。
• 实际稳定值：在持续压力下，系统能长期维持的吞吐量。

我在项目中遇到过，某厂商的签名卡标称 10000 TPS，实际压测 5 分钟后直接掉到 3000。为什么？散热跟不上，芯片降频了。所以，只看峰值没有意义，稳定值才是真本事。

延迟（Latency）

延迟分三种：平均延迟、P99 延迟、最大延迟。你猜哪个最要命？

平均延迟会骗人。举个例子，100 个请求里 99 个 1ms，1 个 100ms，平均才 1.99ms，看起来很美。但那个 100ms 的请求，可能就是你的用户正在等的那个。

我建议重点关注 P99 延迟——也就是 99% 的请求都在这个时间以内完成。签名验签场景里，P99 超过 50ms 就已经很危险了，尤其是高频交易场景。

指标	含义	关注点
平均延迟	所有请求延迟的算术平均	容易掩盖长尾问题
P99 延迟	99% 请求的延迟上限	真实用户体验
最大延迟	最慢的那个请求	极端情况下的系统瓶颈

CPU 占用

CPU 占用率反映的是系统资源消耗情况。签名验签是计算密集型任务，CPU 占用高是常态。但这里有个误区：CPU 占用 100% 不代表系统在全力干活。

你想想看，如果 CPU 一直在等 I/O（比如读密钥文件、写日志），占用率再高也没用。这时候要看 CPU 的 user 态和 sys 态占比。user 态高说明计算在跑，sys 态高说明系统调用频繁，可能有锁竞争。

我习惯用 top 和 perf 配合着看。先看 CPU 占用率，再用 perf top 看热点函数。有一次我发现验签慢，就是因为一个锁的争抢占了 30% 的 CPU 时间。

测试环境搭建原则

环境搭不对，数据全白费。这不是危言耸听。我见过有人用笔记本压测服务器，结果网络成了瓶颈；也见过压测机和目标机共用同一块磁盘，结果 I/O 互相干扰。

下面这几个原则，是我踩坑踩出来的。

原则一：隔离

压测机、目标机、监控机必须物理隔离。说白了，就是三台不同的机器。

• 压测机：只负责发请求、收响应、记日志。
• 目标机：只运行签名验签服务。
• 监控机：只采集指标，不参与压测。

为什么？因为压测机本身也会消耗 CPU 和网络。如果它和目标机抢资源，测出来的数据就不准了。

原则二：网络环境要可控

网络延迟和丢包率对签名验签性能影响很大。尤其是验签场景，如果密钥需要从远程获取，网络抖动会直接放大延迟。

我建议：

• 压测机和目标机之间用 万兆直连，不要过交换机。
• 如果必须过交换机，提前用 ping 和 iperf 测试网络质量。
• 记录网络延迟基线，方便后续分析。

原则三：硬件配置要一致

签名验签对 CPU 指令集敏感。同样是 Intel 的 CPU，支持 AVX-512 和不支持，性能能差一倍。

所以，测试环境必须和生产环境硬件一致。至少：

• CPU 型号、主频、核心数一致。
• 内存大小和频率一致。
• 磁盘类型（SSD 还是 HDD）一致。

我曾经吃过这个亏。开发环境用 i9-13900K，生产环境是 Xeon Gold 6330，结果验签性能差了 40%。查了半天，发现是 AVX-512 指令集的支持差异。

原则四：软件环境要标准化

操作系统、内核版本、依赖库版本，全部锁定。不要今天用 Ubuntu 20.04，明天换 22.04。内核参数也要统一，尤其是：

• net.core.somaxconn：最大连接数。
• vm.swappiness：内存交换策略。
• kernel.sched_migration_cost_ns：进程迁移成本。

我习惯用 Docker 容器来固化环境。把操作系统、依赖、签名验签服务全部打包成一个镜像，每次测试都用同一个镜像启动。这样能最大程度减少环境差异。

知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作一个检查清单，每次做性能测试前过一遍。

避坑指南

最后，分享几个我踩过的坑，希望能帮你省点时间。

• 不要用笔记本压测。笔记本的散热和电源管理会主动降频，测出来的数据完全不可信。
• 预热很重要。签名验签服务刚启动时，JIT 编译、缓存填充都没完成，前几百个请求的数据要丢掉。
• 监控要全覆盖。除了 CPU，还要看内存、磁盘 I/O、网络、甚至温度。有一次我发现性能下降，最后查出来是机柜温度过高导致风扇全速运转，CPU 被降频了。
• 记录一切。每次测试的环境参数、软件版本、压测脚本、原始数据，全部归档。不然三个月后你根本想不起来当时是怎么测的。