第三章 性能基准测试：测试方法论、关键性能指标(KPI)、测试环境搭建
性能基准测试，说白了就是给火控系统做一次「体检」。
你得知道它现在跑得怎么样，才能谈优化。我见过不少团队，一上来就闷头调参数，结果调了半天，连系统到底慢在哪都没搞清楚。嗯，这活儿得按规矩来。
3.1 测试方法论：别瞎测，得有章法
我个人习惯把基准测试分成三个层次：
- 单元级测试：测单个模块，比如卡尔曼滤波器的计算耗时。
- 链路级测试：测一条完整的数据链，从传感器输入到火控解算。
- 系统级测试：全系统跑起来，模拟真实战场环境。
你想想看，如果单元级就慢了，链路级和系统级肯定好不了。所以我的建议是：从下往上测，逐层定位瓶颈。
核心原则：控制变量法。每次只改一个参数，其他保持不变。我曾经犯过这个错——一次改了三个参数，结果性能提升了，但根本不知道是哪个起了作用。后来花了三天重新测，得不偿失。
还有一个容易被忽略的点：预热。火控系统刚启动时，缓存是冷的，第一次运算往往偏慢。我习惯先跑几轮「热身数据」，等系统稳定了再开始记录。否则你测出来的数据，其实反映的是冷启动性能，不是稳态性能。
3.2 关键性能指标(KPI)：盯住这几个数就够了
KPI 不能贪多。我见过有人列了二十多个指标，最后哪个都没盯住。其实火控系统最核心的就这几个：
| 指标 | 含义 | 我的经验阈值 |
|---|---|---|
| 解算延迟 | 从输入到输出火控诸元的时间 | ≤ 50ms（对空目标要求更高） |
| 帧率稳定性 | 每秒解算次数的波动范围 | 波动 ≤ 5% |
| CPU 占用率 | 火控进程占用的 CPU 百分比 | 峰值 ≤ 70%，留余量给其他任务 |
| 内存抖动 | 内存分配/释放的频率 | 尽量避免频繁分配 |
| 中断响应时间 | 从硬件中断到 ISR 开始执行 | ≤ 10μs |
这里我想多说一句「内存抖动」。很多新手只盯着 CPU，其实内存分配太频繁，会导致 cache 命中率下降，CPU 反而在等数据。我在项目中遇到过，一个模块每秒分配释放上千次小对象，CPU 占用率直接飙到 85%。后来改成对象池，降到了 40%。
小技巧：用 perf 工具看 cache-misses 比例。如果超过 10%，说明内存布局有问题，该考虑数据局部性优化了。
3.3 测试环境搭建：别让环境坑了你
环境搭建这件事，看着简单，其实最容易出幺蛾子。我总结了几条铁律：
- 硬件环境要锁定：CPU 频率、内存频率、甚至 BIOS 版本都要记录。有一次我换了块主板，性能差了 15%，查了半天才发现是 BIOS 的功耗管理策略不同。
- 软件环境要隔离：关掉不必要的后台服务。特别是 Windows 下的自动更新、杀毒软件，它们会突然抢 CPU。
- 网络环境要模拟：火控系统经常涉及多节点通信。别用真实网络测，用网络模拟器注入延迟和丢包，看看系统扛不扛得住。
下面是我常用的一个测试环境配置模板：
# 测试环境配置清单
硬件平台: Intel i7-12700, 32GB DDR5, NVMe SSD
操作系统: Ubuntu 22.04 LTS (内核 5.15)
实时性: 启用 PREEMPT_RT 补丁
网络模拟: NetEm (注入 5ms 延迟, 0.1% 丢包)
监控工具: perf, htop, valgrind (内存检查)
注意：千万别在生产环境上直接跑基准测试！我曾经有个同事，直接在实装系统上跑压力测试，结果把火控雷达的通信链路堵死了，差点酿成事故。测试环境必须独立，哪怕用虚拟机都行，但一定要隔离。
还有一个细节：温度控制。CPU 温度高了会降频，性能直接打折扣。我习惯在测试前先跑 10 分钟压力负载，让温度稳定下来，然后再开始正式测试。这样测出来的数据才真实反映系统在持续运行时的表现。
嗯，基准测试这块，方法论、KPI、环境搭建，三者缺一不可。方法论保证你测得对，KPI 保证你盯得准，环境搭建保证你测得稳。下一章我们聊聊具体怎么用工具抓性能数据，到时候我会分享几个我常用的命令行组合拳。