性能基准¶
项目用 Criterion 微基准、可控多连接测试和 Linux 进程级启动基准分别观察 CPU、分配、并发尾延迟与启动资源。网络 RTT、市场状态和后端限流不应与 OpenD 本地 CPU 成本混为一谈。
基准套件¶
| 范围 | 命令 | 主要观察点 |
|---|---|---|
| API key / 限额 | cargo bench -p futu-auth --bench auth_bench |
hash-index lookup、共享 key generation、borrowed limit policy |
| 行情缓存 | cargo bench -p futu-cache --bench cache_lookup |
static/QOT cache hit、cache-key、ticker 窄读取 |
| 帧编解码 | cargo bench -p futu-codec |
44-byte header、frame encode/decode |
| 加密 | cargo bench -p futu-net |
AES ECB 典型 body 大小 |
| SQLite | cargo bench -p futu-gateway-core --bench stock_db_lookup |
150k 行 code / warrant-owner 查询 |
| 遥测与 WS | cargo bench -p futu-core --bench delay_stats、cargo bench -p futu-server --bench ingress_and_metrics |
delay counter contention、精确 latency ring、WS binary slicing |
KeyStore::verify 使用按 hash 构建的不可变 generation，不随 key 数量线性扫描。行情和静态缓存也有独立 benchmark；旧文档中的固定微秒数字不再作为跨机器 SLO。
可比较运行¶
同一次裁决必须使用相同机器、Rust 工具链、Cargo profile 和 fixture。至少运行五个独立进程；Criterion 单进程内部 sample 不能替代独立进程。
# 保存同一源码/环境的基线
cargo bench -p futu-auth --bench auth_bench -- --save-baseline perf-before
# 产品改动后比较
cargo bench -p futu-auth --bench auth_bench -- --baseline perf-before
scripts/perf_acceptance.py 对机器可读结果做 fail-closed 裁决：缺 cell、少于五进程、machine/profile/input 不一致、置信区间重叠或明确回退都不能成为假绿。置信区间重叠时结果是 INCONCLUSIVE，不通过微调代码制造“提升”。
Linux 启动与资源边界¶
scripts/linux_stock_cache_benchmark.py 使用事故规模 stock cache，连续五次记录监听就绪、CPU、RSS、线程与文件描述符。previous release 与 candidate 都必须由调用者显式提供 archive、SHA-256 和完整 source SHA；脚本不再下载或固定比较旧的 v1.5.2。
候选还必须独立满足绝对边界：五次全部就绪、无超时/异常退出、TCP 最大 120 秒、P95 90 秒、RSS 不超过 2 GiB、就绪后平均 CPU 不超过 50%。相对更快不能覆盖绝对边界失败。
解释结果¶
- 本地 cache API 可观察到微秒甚至更低的 CPU 差异，适合评估分配和锁竞争。
- 会访问 Futu backend 的 API 通常由网络 RTT 主导；本地优化不能宣称降低 backend latency。
- internal candidate 使用
release-ci（Thin LTO），本地--release使用完整 LTO；不同 profile 的数字不可直接比较。 - benchmark 通过只证明指定机器和输入的性能合同，不等于五平台、真机行情/交易或 release-ready。
Criterion HTML 报告位于 target/criterion/report/index.html，该目录是本地产物，不提交到仓库。