一、性能基准与目标设定：为什么需要基准？如何定义延迟、吞吐量、抖动等核心指标
做量化交易系统这么多年，我见过太多团队一上来就撸代码，结果上线后才发现——系统跑得慢，但说不清慢在哪。没有基准，你连自己到底行不行都不知道。
说白了，基准就是一把尺子。你用它量一量，才知道系统是胖了还是瘦了。我个人习惯，在写第一行代码之前，先把这个尺子定好。
1.1 为什么需要性能基准？
你想想看，没有基准会怎样？
- 优化了半天，自我感觉良好，结果一测，延迟反而高了
- 换了硬件，觉得肯定快了，但实际效果没人说得清
- 团队里你说快，他说慢，吵半天没有结论
我在项目中遇到过一件事。有个同事说他的模块延迟只有10微秒，我拿基准一测，好家伙，实际是50微秒。为什么？他测的是单线程空闲状态，而线上是并发压力场景。基准没定好，数据就是骗人的。
1.2 延迟：系统响应的快慢
延迟，就是一笔订单从发出去到收到确认，花了多长时间。单位通常是微秒（μs）或纳秒（ns）。
这里有个坑，我刚开始做交易系统时也踩过。延迟不是只有一个数字，它分好几种：
| 延迟类型 | 定义 | 典型场景 |
|---|---|---|
| 网络延迟 | 数据包在网络上传输的时间 | 从交易服务器到交易所 |
| 处理延迟 | 系统内部处理订单的时间 | 订单校验、风控检查 |
| 端到端延迟 | 从客户端发起到收到响应的总时间 | 用户感知的完整交易流程 |
我个人习惯，重点看端到端延迟。因为用户只关心这个。你内部优化得再好，网络一堵，用户照样骂娘。
1.3 吞吐量：系统能扛多少活
吞吐量，就是单位时间内系统能处理多少笔交易。常见单位是TPS（Transactions Per Second，每秒交易笔数）。
你想想看，延迟和吞吐量是什么关系？
很多人以为延迟低，吞吐量就一定高。其实不一定。我见过一个系统，单笔延迟只有5微秒，但并发一上来，吞吐量直接崩了。为什么？因为它的架构是串行的，来一笔处理一笔，来多了就排队。
吞吐量的测量，要注意两个点：
- 峰值吞吐量：系统能承受的最大压力，再高就崩了
- 持续吞吐量：系统能长期稳定运行的吞吐量
我在项目中遇到过，有个系统峰值能扛10万TPS，但持续跑5分钟就过热降频。这种系统，你敢用吗？
1.4 抖动：稳定性的隐形杀手
抖动，说白了就是延迟的波动。你测100次延迟，有的5微秒，有的50微秒，有的甚至100微秒。这种波动，就叫抖动。
为什么抖动这么重要？
你想想看，量化交易里，策略是依赖稳定延迟的。如果延迟忽高忽低，策略的预测模型就会失效。我见过一个团队，平均延迟只有10微秒，但抖动高达200微秒。结果呢？策略在低延迟时赚钱，在高延迟时亏钱，最后整体是亏的。
抖动的衡量指标，常用的是：
- P99延迟：99%的请求延迟低于这个值
- P999延迟：99.9%的请求延迟低于这个值
- 标准差：延迟数据的离散程度
我个人习惯，重点看P99和P999。平均延迟可以骗人，但P99不会。你想想看，100笔交易里，有1笔延迟特别高，那1笔可能就让你亏大钱。
1.5 如何设定性能目标？
基准有了，指标也清楚了，接下来就是定目标。目标怎么定？
我建议分三步走：
- 摸底：先跑一遍基准，看看当前系统是什么水平
- 对标：看看行业标准或竞争对手是什么水平
- 定标：结合业务需求，定一个合理的目标
举个例子，我之前做一个高频交易系统，摸底发现端到端延迟是50微秒。对标行业，头部玩家是10微秒。业务需求呢？策略要求20微秒以内。最后目标定在15微秒，留点余量。
1.6 核心知识体系
下面这张图，是我整理的核心知识体系。你一看就明白，基准、延迟、吞吐量、抖动之间的关系。
1.7 总结
基准是起点，没有它，你连自己在哪都不知道。延迟、吞吐量、抖动，这三个指标缺一不可。只看延迟，你会忽略吞吐量；只看平均延迟，你会被抖动坑死。
我个人习惯，每次优化前先跑一遍基准，优化后再跑一遍。对比一下，心里就有数了。嗯，这就是基本功，没什么花哨的。
公众号:蓝海资料掘金营，微信deep3321