Skip to content

BENCHMARK.md

Latest commit

 

History

History
121 lines (88 loc) · 3.63 KB

BENCHMARK.md

File metadata and controls

121 lines (88 loc) · 3.63 KB

AeroX 性能测试 (Benchmark)

这是一个多线程多用户性能测试demo，用于测试AeroX服务器在高并发下的性能表现。

功能特性

✅ 256个并发客户端 - 全局配置，可随时修改 ✅ 异步收发消息 - 使用tokio异步运行时 ✅ 服务器原路返回 - Echo服务器，收到消息原样返回 ✅ 精确计时统计 - 15秒测试窗口，统计QPS

运行方法

cargo run --example benchmark

配置修改

在 benchmark.rs 文件的 BenchmarkConfig 结构体中修改：

impl BenchmarkConfig {
    const fn default() -> Self {
        Self {
            server_addr: "127.0.0.1:8080",  // 服务器地址
            num_clients: 256,                // 客户端数量 (可修改)
            duration_secs: 15,               // 测试时长(秒) (可修改)
        }
    }
}

输出示例

╔══════════════════════════════════════════╗
║   AeroX 性能测试 (Benchmark)           ║
╚══════════════════════════════════════════╝

📊 测试配置:
  • 客户端数量: 256
  • 测试时长: 15 秒
  • 服务器地址: 127.0.0.1:8080

🚀 启动性能测试服务器...
📡 监听地址: 127.0.0.1:8080
👥 预期客户端数: 256

AeroX TCP Reactor 启动:
  监听地址: 127.0.0.1:8080
  工作线程数: 8
  缓冲区大小: 8192

🔗 开始创建客户端连接...
✅ 256 个客户端已创建完成

🚀 开始性能测试...
⏱️  测试进行中...

⏹️  测试结束，等待客户端完成...

╔══════════════════════════════════════════╗
║           测试结果统计                   ║
╚══════════════════════════════════════════╝

  ⏱️  实际运行时间: 15.23 秒
  📨 总消息数量: 125432
  📊 QPS (每秒查询数): 8236.54

  性能评级: ⚠️  需要优化 (Needs Optimization)

✅ 性能测试完成！

性能评级标准

  • 🏆 优秀 (Excellent): QPS ≥ 100,000
  • 👍 良好 (Good): QPS ≥ 50,000
  • ✓ 及格 (Acceptable): QPS ≥ 10,000
  • ⚠️ 需要优化 (Needs Optimization): QPS < 10,000

技术实现

服务器端

  • 使用 AeroX 的 Server::bind() API
  • 注册单个路由处理器 MSG_ID_REQUEST
  • 收到消息后立即返回 (Echo模式)
  • 8个Worker线程并发处理连接

客户端

  • 256个独立tokio任务
  • 每个客户端维护独立连接
  • 使用 AtomicU64 线程安全地统计总消息数
  • 使用 Semaphore 同步所有客户端同时开始
  • 精确控制测试时长

统计机制

  • AtomicU64 计数器：无锁线程安全
  • should_stop 标志：确保只统计测试期间的消息
  • 精确计时：从第一个客户端创建开始计时

优化建议

如果性能评级不理想，可以尝试：

  1. 增加Worker数量 - 修改 aerox_config 中的 worker_threads
  2. 调整缓冲区大小 - 增加 reactor_buffer_size
  3. 优化消息处理 - 减少handler中的处理逻辑
  4. 使用release模式 - cargo run --example benchmark --release

性能测试最佳实践

  1. 关闭其他程序 - 确保系统资源充足
  2. 多次运行取平均值 - 单次测试可能受系统状态影响
  3. 逐步增加客户端数 - 从64开始，逐步增加到256、512、1024
  4. 监控资源使用 - 使用 htop 或 Activity Monitor 查看CPU/内存使用

License

MIT