2. 性能指标定义：延迟、吞吐量、抖动、资源利用率、性能指标间的权衡
聊性能分析，第一个绕不开的问题就是：你到底要优化什么？
我见过不少团队，一上来就盯着延迟猛干，结果吞吐量上不去，系统反而更卡了。说白了，性能优化不是单点突破，而是一套组合拳。你得先搞清楚每个指标的含义，才能知道往哪个方向使劲。
2.1 延迟（Latency）
延迟，就是一笔交易从发起到确认的时间。在套利系统里，这通常指订单从策略发出，到交易所返回成交确认的耗时。
我个人习惯把延迟拆成三段：
- 网络延迟：数据在网线上跑的时间。跨洲交易，光速就是物理极限，谁也没办法。
- 系统延迟：数据在CPU、内存、网卡之间流转的时间。这部分是我们可以优化的主战场。
- 排队延迟：请求在队列里等着被处理的时间。高并发下，这是大头。
我在项目中遇到过最头疼的事：明明网络延迟只有1ms，但系统延迟却飙到了50ms。查了半天，发现是日志打印阻塞了IO线程。嗯，有时候问题就出在这些不起眼的地方。
核心观点：延迟不是越低越好，而是要在可接受的范围内，找到成本和收益的平衡点。
2.2 吞吐量（Throughput）
吞吐量，单位时间内能处理多少笔交易。常见单位是TPS（Transactions Per Second）。
你想想看，延迟是单笔交易的速度，吞吐量是系统的整体处理能力。两者有关系，但不是线性关系。
举个例子：
- 延迟10ms，吞吐量可能只有100 TPS
- 延迟20ms，吞吐量可能达到1000 TPS
为什么会这样？因为系统可以并行处理。延迟高了，但并发度上去了，整体吞吐量反而更大。
我曾经优化过一个套利策略，把延迟从5ms降到了2ms，结果吞吐量只提升了10%。后来发现瓶颈在数据库写入，跟网络延迟关系不大。所以，别盲目追求低延迟，先看看瓶颈在哪。
2.3 抖动（Jitter）
抖动，就是延迟的波动程度。说白了，延迟不稳定。
我习惯用P99、P999来衡量抖动。比如P99延迟是100ms，意味着99%的请求在100ms内完成，剩下1%可能跑到500ms甚至更高。
在套利系统里，抖动比高延迟更可怕。为什么？
- 高延迟是稳定的慢，你可以通过调整策略来适应
- 抖动是忽快忽慢，你的策略根本没法预测
我记得有一次，系统P50延迟只有2ms，但P999延迟经常跳到200ms。结果就是，大部分交易都正常，但偶尔一笔交易卡住，导致整个策略节奏被打乱。后来发现是JVM的GC在作祟。
避坑指南：我曾经因为忽略了抖动，导致一个高频策略在实盘中频繁亏损。后来加了抖动监控，才发现问题。记住，稳定的低延迟，比偶尔的超低延迟更重要。
2.4 资源利用率（Resource Utilization）
资源利用率，就是CPU、内存、网络、磁盘等硬件资源的使用情况。
很多人觉得资源利用率越高越好，其实不然。CPU跑到90%以上，说明系统快扛不住了，随时可能崩溃。我一般建议：
- CPU利用率控制在70%以下
- 内存使用率控制在80%以下
- 网络带宽使用率控制在60%以下
为什么留这么多余量？因为系统需要应对突发流量。你想想看，如果平时CPU就跑到95%，突然来一波行情，系统直接挂掉，那损失可就大了。
2.5 性能指标间的权衡
这几个指标不是独立的，它们之间存在着复杂的权衡关系。我画了一张图，帮你理清思路：
从这张图你能看出几个关键权衡：
| 权衡关系 | 说明 | 实际案例 |
|---|---|---|
| 延迟 vs 吞吐量 | 降低延迟通常意味着减少并发，吞吐量会下降 | 把单线程改成多线程，延迟可能增加，但吞吐量翻倍 |
| 延迟 vs 抖动 | 过度优化延迟，可能导致系统不稳定，抖动加剧 | 关闭GC来降低延迟，但内存泄漏会导致抖动飙升 |
| 吞吐量 vs 资源利用率 | 提高吞吐量，资源利用率必然上升 | 增加线程数，CPU利用率从50%升到90% |
| 抖动 vs 资源利用率 | 资源利用率过高，抖动会显著增加 | CPU跑到95%时，P99延迟可能翻10倍 |
我的经验：做性能优化，先定目标。你是要低延迟，还是要高吞吐？两者不可兼得时，根据业务场景做取舍。套利系统通常优先保证低延迟和低抖动，吞吐量够用就行。
2.6 如何选择性能指标
不同场景，关注的重点不一样。我列了个清单，供你参考：
- 高频套利：延迟 > 抖动 > 吞吐量 > 资源利用率
- 统计套利：吞吐量 > 延迟 > 资源利用率 > 抖动
- 做市商系统：抖动 > 延迟 > 吞吐量 > 资源利用率
你看，同样是套利系统，策略不同，指标优先级完全不同。所以别照搬别人的优化方案，先搞清楚自己的业务特点。
嗯，这一章的内容就到这里。记住一句话：没有完美的系统，只有合适的权衡。下一章我们聊聊具体的性能测试方法，到时候我会分享一些压测工具的使用技巧。
公众号:蓝海资料掘金营，微信deep3321