2、关键性能指标(KPI)：延迟、吞吐量、抖动、资源利用率、最大并发数
聊性能基准测试，咱们得先统一度量衡。
你想想看，如果连「快」和「慢」的标准都没定好，那测试结果就是一笔糊涂账。我个人习惯，在搭建任何交易系统之前，先把这五个核心指标焊死在脑子里。它们就像汽车的仪表盘——缺一个，你都不知道车什么时候会爆缸。
2.1 延迟（Latency）—— 从订单到成交的「心跳」
延迟，说白了就是一条指令从发出到确认的时间差。在交易系统里，它通常指「订单进入系统」到「订单被交易所确认」之间的耗时。
为什么它这么要命？
因为高频交易里，1微秒的延迟可能意味着几十万美元的价差。我记得有一次帮一家做市商做优化，发现他们的延迟中位数只有5微秒，但P99（99%分位）却飙到了200微秒。嗯，这就是典型的「长尾延迟」问题——平时看着挺快，关键时刻掉链子。
核心度量方式：
- 平均延迟：容易算，但容易被极端值带偏。我一般只看P50、P99、P999。
- P99延迟：99%的请求都在这个时间内完成。这是交易系统的生命线。
- 最大延迟：最差情况下的表现。如果这个值超过你的风控阈值，系统就该报警了。
避坑指南：
我曾经踩过一个坑：用软件时间戳去测网络延迟。结果发现，操作系统调度本身就会引入几十微秒的误差。后来我改用DPDK的硬件时间戳，才把测量精度拉到纳秒级。记住：测不准的指标，比没测更危险。
2.2 吞吐量（Throughput）—— 系统的「消化能力」
吞吐量，就是单位时间内系统能处理多少笔交易。通常用「每秒订单数」（Orders Per Second, OPS）来衡量。
你可能会问：延迟低，吞吐量就一定高吗？不一定。我见过一个系统，单笔延迟只有1微秒，但并发一上来就卡死。为什么？因为它的处理逻辑是串行的，吞吐量被锁死在单核上。
吞吐量的两个关键维度：
- 峰值吞吐量：系统在极限压力下能扛住的最大值。我习惯用「压力测试」来摸这个天花板。
- 持续吞吐量：系统在稳定运行下能长期维持的值。这个值通常比峰值低30%-50%。
注意：
吞吐量不是越高越好。我曾经接手过一个项目，团队把吞吐量从10万OPS优化到了50万OPS，结果发现延迟从10微秒飙到了500微秒。这就是典型的「以延迟换吞吐」——在交易系统里，这往往是自杀行为。
2.3 抖动（Jitter）—— 系统的「心律不齐」
抖动，就是延迟的波动程度。你可以把它想象成心跳——稳定的心跳是60次/分，但偶尔漏跳一拍，那就是抖动。
在交易系统里，抖动比高延迟更可怕。为什么？因为高延迟你可以预测，比如网络延迟固定是10毫秒，你可以在策略里做补偿。但抖动是随机的——上一笔订单1微秒，下一笔突然变成100微秒，你的策略根本来不及反应。
我常用的抖动度量方法：
- 标准差：简单粗暴，但能反映整体波动情况。
- 延迟分布图：把延迟按时间画出来，一眼就能看出有没有「毛刺」。
- 最大-最小差值：最直观的抖动指标。如果这个值超过平均延迟的10倍，系统就有问题。
实战经验：
我记得有一次排查抖动问题，发现罪魁祸首竟然是Java的GC（垃圾回收）。每次GC触发时，系统会暂停所有线程，导致延迟瞬间飙升。后来我们改用低延迟的ZGC，才把抖动压下去。嗯，这里要注意：任何「暂停」行为，都是抖动的温床。
2.4 资源利用率—— 硬件的「体检报告」
资源利用率，就是CPU、内存、网络、磁盘等硬件被占用的比例。它不直接决定性能，但能告诉你「瓶颈在哪」。
我重点关注这几个指标：
- CPU使用率：如果超过80%，说明计算资源吃紧。但要注意，不是所有CPU时间都有用——上下文切换、中断处理这些「开销」也算在内。
- 内存带宽：交易系统里，内存带宽往往比CPU频率更重要。因为数据量大，频繁的内存拷贝会拖垮性能。
- 网络带宽：尤其是网卡的中断频率。我习惯用「每秒数据包数」（Packets Per Second, PPS）来衡量，而不是单纯的带宽。
一个小技巧：
我曾经发现一个系统的CPU利用率只有30%，但延迟却很高。排查后发现，是网卡的中断处理占用了大量CPU时间，但操作系统没把它算进「用户态CPU」。后来我改用perf工具分析，才找到真凶。所以，别只看top命令，它有时候会骗你。
2.5 最大并发数—— 系统的「承重墙」
最大并发数，就是系统在不崩溃的前提下，能同时处理多少个连接或订单。它和吞吐量有关，但不是一回事。吞吐量是「每秒处理多少」，并发数是「同一时刻有多少在排队」。
为什么并发数重要？
因为交易系统里，行情数据是广播式的——一秒内可能涌入几万笔报价。如果并发数设计不足，系统会直接拒绝连接，或者开始丢包。我见过最惨的一次，是某交易所的网关在行情爆发时，因为并发连接数超限，直接OOM（内存溢出）了。
并发数的设计原则：
- 理论峰值：根据历史数据，估算最大并发数。我一般会留50%的余量。
- 实际测试：用压测工具模拟并发连接，看系统在哪个点开始报错。
- 资源关联：并发数不是孤立的。它和内存、文件描述符、线程池大小都有关。我曾经把线程池从100调到1000，结果并发数上去了，但上下文切换开销把CPU打满了。
警告：
不要迷信「无限制并发」。有些框架号称支持百万并发，但实际跑起来，光TCP连接的内存开销就能吃掉几十GB。我建议：先算一笔账——每个连接需要多少内存、多少CPU时间，再决定并发上限。
2.6 五个指标的关系图
下面这张图，是我自己总结的五个指标之间的关联。你可以把它当成一张「体检表」——任何一个指标异常，都能顺着箭头找到根因。
这张图里，箭头表示「影响方向」。比如，延迟上升通常会导致吞吐量下降（负相关），而资源利用率过高会推高延迟。我个人习惯在每次压测后，都画一张这样的图，看看哪个指标先「爆表」。
2.7 如何选择核心指标？
五个指标都重要，但不同场景侧重点不同。我一般这样选：
- 高频做市：延迟和抖动是命根子。吞吐量够用就行，别贪多。
- 量化套利：吞吐量和最大并发数更重要。因为要同时监控几十个市场。
- 风控系统：资源利用率和抖动。风控不能有毛刺，否则会误杀。
我的习惯：
每次做基准测试，我都会先定一个「目标指标」。比如这次只优化延迟，那其他四个指标只要不恶化就行。别想一口吃成胖子——我曾经试图同时优化五个指标，结果改了一个月，哪个都没做好。
好了，这五个指标就聊到这儿。记住一句话：没有完美的指标，只有适合场景的指标。下一章，咱们聊聊怎么搭一个靠谱的测试环境——那才是真正动手的开始。