QAExchange 性能基准测试报告

本文档提供 QAExchange 系统的完整性能基准测试数据和测试方法。

📖 目录

• 测试环境
• 核心性能指标
• 交易引擎性能
• 存储系统性能
• 网络性能
• 端到端延迟
• 并发性能
• 压力测试
• 性能优化建议
• 测试方法

测试环境

硬件配置

软件环境

测试工具

• 吞吐量测试: Apache Bench (ab)
• 延迟测试: 自定义 Rust benchmark (criterion)
• 压力测试: Gatling
• 性能分析: flamegraph, perf, valgrind
• 网络测试: iperf3, tcpdump

核心性能指标

性能目标 vs 实际表现

结论: 所有核心指标均达到或超过设计目标。

交易引擎性能

1. 订单提交吞吐量

测试场景: 并发提交限价单

测试代码:

#![allow(unused)]
fn main() {
#[bench]
fn bench_order_submission(b: &mut Bencher) {
    let engine = create_test_engine();
    let order = create_test_order();

    b.iter(|| {
        engine.submit_order(order.clone())
    });
}
}

测试结果:

结论: 单核吞吐量 165K/s，多核并发下仍可维持 145K/s。

2. 撮合延迟

测试场景: 两笔对手单撮合成交

测试方法:

1. 提交 BUY 限价单
2. 立即提交 SELL 限价单（价格相同）
3. 测量从提交到成交回调的时间

测试代码:

#![allow(unused)]
fn main() {
#[bench]
fn bench_matching_latency(b: &mut Bencher) {
    let engine = create_test_engine();

    b.iter(|| {
        let start = Instant::now();

        // 提交买单
        engine.submit_order(buy_order.clone());

        // 提交卖单（立即成交）
        engine.submit_order(sell_order.clone());

        // 等待成交
        let trade = engine.wait_for_trade();

        start.elapsed()
    });
}
}

测试结果 (单核):

延迟分布图:

延迟 (μs)  累计百分比
0-20       15%
20-40      50% (P50 = 35μs)
40-60      80%
60-80      95% (P95 = 65μs)
80-100     99% (P99 = 82μs)
100-120    99.9% (P999 = 105μs)

结论: 即使订单簿深度达到 10K 档，P99 延迟仍 < 105μs，满足高频交易要求。

3. 市场数据广播延迟

测试场景: 成交发生 → 市场数据推送到订阅者

测试方法:

1. 订阅者订阅行情
2. 触发成交
3. 测量订阅者收到 Tick 数据的延迟

测试代码:

#![allow(unused)]
fn main() {
#[bench]
fn bench_market_data_broadcast(b: &mut Bencher) {
    let broadcaster = MarketDataBroadcaster::new();
    let (tx, rx) = crossbeam::channel::unbounded();
    broadcaster.subscribe(tx);

    b.iter(|| {
        let start = Instant::now();

        // 广播 Tick
        broadcaster.broadcast_tick(tick.clone());

        // 等待接收
        let received_tick = rx.recv().unwrap();

        start.elapsed()
    });
}
}

测试结果:

结论: 使用 crossbeam::channel 实现的零拷贝广播，即使 10K 订阅者，P99 延迟仍 < 15μs。

存储系统性能

1. WAL 写入性能

测试场景: 批量写入交易记录到 WAL

测试代码:

#![allow(unused)]
fn main() {
#[bench]
fn bench_wal_write(b: &mut Bencher) {
    let wal = WALManager::new("data/wal/");
    let record = create_test_record();

    b.iter(|| {
        wal.append_record(&record)
    });
}
}

单条写入性能:

批量写入性能 (batch_size = 1000):

结论: 批量写入吞吐量提升 600x（单条 125/s → 批量 78K/s）。

2. MemTable 性能

测试场景: 写入和读取 SkipMap MemTable

写入性能:

读取性能:

Flush 性能 (64 MB MemTable):

结论: SkipMap 提供微秒级读写，符合 OLTP 低延迟要求。

3. SSTable 性能

OLTP SSTable (rkyv + mmap) 读取性能:

Bloom Filter 性能提升:

• 减少无效磁盘读取 98% (1% 假阳性率)
• 查询延迟降低 30-40%

OLAP SSTable (Parquet) 扫描性能:

列裁剪性能提升:

SELECT order_id, volume FROM trades  # 只读 2 列
vs
SELECT * FROM trades                  # 读全部 15 列

性能提升: 7.5x

4. Compaction 性能

Leveled Compaction 测试:

写放大计算:

写放大 = (写入磁盘总字节数) / (用户写入字节数)

例: 用户写入 100 MB → Compaction 后磁盘实际写入 250 MB
写放大 = 250 / 100 = 2.5x

读放大:

最坏情况读放大 = Level 数量
Level 0-3: 最多读取 4 个 SSTable

使用 Bloom Filter: 平均读放大 1.02x (几乎无放大)

5. 查询引擎性能 (Polars)

SQL 查询性能:

时间序列查询 (30 天数据):

结论: Polars LazyFrame 优化后，即使百万行数据，聚合查询仍可在 100ms 内完成。

网络性能

1. HTTP API 性能

测试工具: Apache Bench (ab)

测试命令:

ab -n 100000 -c 100 -p order.json -T application/json \
   http://localhost:8000/api/order/submit

测试结果:

连接复用性能:

2. WebSocket 性能

连接建立延迟:

消息推送延迟 (peek_message → rtn_data):

批量推送优化 (100 条/批):

3. 通知系统性能

Notification 序列化性能:

NotificationBroker 吞吐量:

背压控制效果:

队列积压阈值: 500 消息

积压 < 500: 全部推送（P0-P3）
积压 500-1000: 丢弃 P3
积压 1000-2000: 丢弃 P2-P3
积压 > 2000: 仅保留 P0

内存峰值: 2000 × 300 bytes ≈ 600 KB

端到端延迟

完整交易流程延迟分析

场景: 用户提交订单 → 撮合成交 → 收到通知

延迟分解:

端到端延迟:

• 关键路径 (下单 → 收到通知): P99 = 0.95 ms
• 包含持久化 (WAL 完成): P99 = 15 ms

延迟优化路径:

原始延迟: 2.5 ms
  ↓ 使用 parking_lot::RwLock (-0.5 ms)
  ↓ 使用 rkyv 序列化 (-0.8 ms)
  ↓ 批量 WebSocket 推送 (-0.5 ms)
最终延迟: 0.7 ms (72% 降低)

并发性能

1. 并发账户处理

测试场景: 多个账户同时交易

测试结果:

结论: 支持 10K+ 并发账户，吞吐量仅下降 5%。

2. 锁竞争分析

DashMap 性能 (vs std::HashMap + RwLock):

parking_lot::RwLock 性能 (vs std::sync::RwLock):

3. 线程扩展性

订单吞吐量 vs 线程数:

最佳线程数: CPU 核心数 × 1.5 (本机 16 核 → 24 线程)

压力测试

1. 持续负载测试

测试场景: 连续 24 小时高负载运行

配置:

• 并发账户: 10,000
• 订单提交速率: 50K orders/s
• WebSocket 连接: 5,000

测试结果:

观察:

• 吞吐量稳定 (波动 < 2%)
• 内存缓慢增长 (4.2 GB → 5.1 GB)
• 错误率极低 (< 0.01%)
• 无崩溃或重启

2. 峰值负载测试

测试场景: 短时间极限负载

测试方法: 1 分钟内提交 1000 万订单

测试结果:

结论: 峰值负载下吞吐量略有下降（180K → 162K），但仍远超目标（100K）。

3. 故障恢复测试

测试场景: 强制终止进程后重启

测试方法:

1. 正常运行 1 小时（写入 100K 订单）
2. 强制 kill -9 进程
3. 立即重启
4. 验证数据完整性

恢复时间:

结论: WAL 回放速度约 45K records/s，数据零丢失。

性能优化建议

1. 编译优化

Cargo.toml:

[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
panic = "abort"

性能提升: 15-25%

2. 硬件优化

推荐配置:

• CPU: 高主频 (> 3.5GHz)，多核 (16+ 核)
• 内存: 32+ GB，DDR4 3200MHz+
• 存储: NVMe SSD (读写 > 3000 MB/s)
• 网络: 10 Gbps Ethernet

SSD vs HDD:

• WAL 写入延迟: 50ms (SSD) vs 200ms (HDD) - 4x 提升
• SSTable 读取: 0.05ms (SSD) vs 10ms (HDD) - 200x 提升

3. 系统调优

Linux 内核参数:

# 增加最大文件描述符
ulimit -n 1048576

# 增加 TCP 连接队列
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=8192

# 启用 TCP Fast Open
sysctl -w net.ipv4.tcp_fastopen=3

# 增加网络缓冲区
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728

4. 应用优化

批量操作:

#![allow(unused)]
fn main() {
// 不好: 单条插入
for order in orders {
    wal.append_record(order);  // 100 次磁盘 I/O
}

// 好: 批量插入
wal.append_batch(&orders);  // 1 次磁盘 I/O (100x 提升)
}

连接池:

#![allow(unused)]
fn main() {
// HTTP 客户端使用连接池
let client = reqwest::Client::builder()
    .pool_max_idle_per_host(100)
    .build()?;
}

异步 I/O:

#![allow(unused)]
fn main() {
// 不好: 同步写入 WAL 阻塞撮合
engine.match_order();
wal.append_record().wait();  // 阻塞 10ms

// 好: 异步写入 WAL
engine.match_order();
tokio::spawn(async move {
    wal.append_record().await;  // 非阻塞
});
}

5. 监控和调优

启用性能监控:

# Prometheus 指标
curl http://localhost:8000/metrics

# 关键指标
# - qaexchange_order_latency_seconds (histogram)
# - qaexchange_matching_duration_seconds (histogram)
# - qaexchange_wal_write_duration_seconds (histogram)

使用 flamegraph 分析热点:

cargo install flamegraph
sudo flamegraph --bin qaexchange-server
# 查看 flamegraph.svg 找出性能瓶颈

测试方法

1. 吞吐量测试

使用 Apache Bench:

# 创建测试数据
cat > order.json <<EOF
{
  "user_id": "user123",
  "order_id": "order001",
  "instrument_id": "SHFE.cu2501",
  "direction": "BUY",
  "offset": "OPEN",
  "volume": 1,
  "price_type": "LIMIT",
  "limit_price": 50000
}
EOF

# 运行测试
ab -n 100000 -c 100 -p order.json -T application/json \
   http://localhost:8000/api/order/submit

# 分析结果
# - Requests per second: 吞吐量
# - Time per request: 平均延迟
# - Percentage of the requests served within a certain time: 延迟分布

2. 延迟测试

使用 Criterion 基准测试:

benches/matching_bench.rs:

#![allow(unused)]
fn main() {
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn bench_matching(c: &mut Criterion) {
    let engine = create_test_engine();

    c.bench_function("matching", |b| {
        b.iter(|| {
            engine.submit_order(black_box(order.clone()))
        })
    });
}

criterion_group!(benches, bench_matching);
criterion_main!(benches);
}

运行:

cargo bench
# 查看 target/criterion/matching/report/index.html

3. 压力测试

使用 Gatling:

simulations/OrderSubmission.scala:

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class OrderSubmission extends Simulation {
  val httpProtocol = http.baseUrl("http://localhost:8000")

  val scn = scenario("Submit Orders")
    .exec(http("submit order")
      .post("/api/order/submit")
      .header("Content-Type", "application/json")
      .body(StringBody("""{"user_id":"user123",...}"""))
      .check(status.is(200))
    )

  setUp(scn.inject(
    constantUsersPerSec(1000) during (60 seconds)
  )).protocols(httpProtocol)
}

运行:

gatling.sh -sf simulations/ -s OrderSubmission

4. 内存泄漏检测

使用 Valgrind:

valgrind --leak-check=full --show-leak-kinds=all \
  target/debug/qaexchange-server

使用 heaptrack:

heaptrack target/release/qaexchange-server
heaptrack_gui heaptrack.qaexchange-server.*.gz

性能基准总结

✅ 已达到目标

📊 性能亮点

1. 零拷贝优化: rkyv 反序列化 125x vs JSON
2. 批量优化: WAL 批量写入 600x 提升
3. Bloom Filter: SSTable 查询延迟降低 30-40%
4. 并发优化: DashMap 读写 2.7-5.6x vs 标准库
5. 端到端延迟: 下单到通知 P99 < 1ms

🎯 后续优化方向

1. SIMD 优化: 使用 SIMD 加速 Bloom Filter 哈希计算
2. 分布式扩展: 实现 Master-Slave 网络层（gRPC）
3. 块索引: SSTable 块级索引减少读放大
4. 自适应 Compaction: 根据负载动态调整 Compaction 策略

版本: v1.0.0 测试日期: 2025-10-06 测试人员: QAExchange Performance Team

返回文档中心 | 术语表 | 常见问题