1. 性能基准测试概述
大家好，我是老张。在量化交易系统这个圈子里摸爬滚打了十几年，今天咱们来聊聊一个绕不开的话题——性能基准测试。
说白了，基准测试就是给系统「称体重、量身高」。你想想看，没有测量就没有改进。我见过太多团队，上来就写代码、上策略，结果上线第一天就被行情数据冲垮了。嗯，这其实是可以避免的。
什么是性能基准测试
基准测试，英文叫 Benchmarking。它是一套标准化的测量方法。目的是评估系统在特定负载下的表现。
我个人习惯把它分成三类：
- 微基准测试：测单个函数或模块。比如一个订单簿更新要多少纳秒。
- 集成基准测试：测完整链路。从行情接入到策略计算再到订单发出。
- 压力基准测试：测极限情况。比如同时涌入 10 万笔订单会怎样。
我在项目中遇到过最典型的例子：某团队说他们的系统延迟只有 5 微秒。结果一测，发现那是空载数据。加上真实行情后，直接飙到 50 微秒。这就是没做基准测试的后果。
核心要点：基准测试不是一次性的。它应该嵌入到你的 CI/CD 流程中。每次代码变更，都要跑一遍。
为什么量化交易系统需要基准测试
这个问题其实很直接。量化交易拼的是什么？速度、精度、稳定性。
我给你们列几个场景：
- 策略回测：你的回测引擎到底准不准？延迟模型对不对？
- 实盘交易：从行情到下单，整个链路能不能跑在 1 毫秒以内？
- 系统扩容：加了一台服务器，性能真的线性提升了吗？
- 技术选型：Kafka 和 RabbitMQ 哪个更适合你的场景？
我曾经帮一家私募做性能诊断。他们的策略在回测时年化收益 30%，实盘却只有 5%。为什么？因为回测时假设延迟为 0，实盘却有 2 毫秒的抖动。这就是基准测试缺失的代价。
避坑指南：我曾经见过有人用 System.currentTimeMillis() 来测延迟。这是大忌！Java 里应该用 System.nanoTime()，C++ 里用 std::chrono::high_resolution_clock。毫秒级的精度在量化交易里根本不够用。
基准测试的核心指标
量化交易系统的性能，主要看三个指标：延迟、吞吐量、抖动。我习惯叫它们「铁三角」。
| 指标 | 英文 | 定义 | 量化交易中的意义 |
|---|---|---|---|
| 延迟 | Latency | 从请求发出到收到响应的时间 | 决定你能不能抢到订单 |
| 吞吐量 | Throughput | 单位时间内处理的请求数 | 决定你能同时跑多少策略 |
| 抖动 | Jitter | 延迟的波动程度 | 决定你的策略是否稳定 |
延迟
延迟是量化交易里最敏感的指标。你想想看，在纳秒级竞争的市场里，1 微秒的差距可能就是盈利和亏损的分界线。
我建议关注这几个分位值：
- P50：中位数延迟。代表典型表现。
- P99：99% 的请求都在这个延迟以内。代表尾部表现。
- P99.9：千分之一的最差情况。这个值往往被忽略，但它最致命。
为什么？因为 P99.9 的延迟抖动，可能让你的止损单晚到了 10 毫秒。这 10 毫秒，行情可能已经跳了 5 个 tick。
个人经验：我习惯用 HDR Histogram 来记录延迟数据。它比平均值靠谱多了。平均值会掩盖很多问题。比如 99% 的请求都是 1 微秒，但 1% 的请求是 100 微秒，平均值才 2 微秒。这能说明问题吗？不能。
吞吐量
吞吐量决定了你的系统能承载多大的业务量。比如你的行情网关每秒能处理多少笔 tick 数据。
这里有个常见的误区：很多人以为吞吐量越高越好。其实不是。吞吐量和延迟是 trade-off。你把吞吐量推到极限，延迟就会飙升。
我一般会这样做：
- 先确定业务要求的最大延迟（比如 1 毫秒）
- 然后在这个约束下，测出最大吞吐量
- 最后留 30% 的余量
举个例子：
// 伪代码：吞吐量测试
int maxLatencyUs = 1000; // 目标延迟上限 1 毫秒
int currentThroughput = 0;
while (true) {
sendRequests(++currentThroughput);
long latency = measureLatency();
if (latency > maxLatencyUs) {
break; // 找到瓶颈了
}
}
System.out.println("最大吞吐量: " + currentThroughput + " req/s");抖动
抖动，说白了就是延迟的「脾气」。有的系统平时很乖，延迟稳定在 10 微秒。但每隔几分钟就抽风一次，跳到 100 微秒。这种系统最可怕。
我遇到过最夸张的一次：某系统的 P50 延迟只有 5 微秒，但 P99.9 延迟达到了 500 微秒。原因是 JVM 的 GC 停顿。后来我们换用了低延迟 GC 算法，才把抖动压下来。
衡量抖动，我推荐两个指标：
- 标准差：反映整体波动情况
- 最大-最小差值：反映极端情况
但说实话，这两个指标都不够直观。我更喜欢看延迟分布图。一眼就能看出有没有「长尾」。
记住：在量化交易里，不是快就好，而是稳才好。一个稳定在 20 微秒的系统，比一个平均 10 微秒但偶尔跳到 100 微秒的系统更可靠。
知识体系总览
下面这张图，是我对性能基准测试核心逻辑的总结。你可以把它当作本章的思维导图。
这张图把本章的核心内容串起来了。你可以看到，三个指标是相互关联的。你不能只盯着一个看。
好了，关于性能基准测试的概述就聊到这里。记住，没有测量就没有改进。下一章咱们会深入聊具体的测试方法和工具。到时候我会分享一些实战中的踩坑经验。