服务器压力测试

测试机（云服务器）

  • 配置：CPU（4 核 ）、内存（8GB）
  • 安全组：允许所有 ip，连接服务器固定端口 port
  • CPU 利用率：
    • 总利用率：200%
    • 单 CPU 利用率：50%

发家机（本地主机）

  • 测试工具：Jmeter

  • 配置：CPU（6 核）、内存（16GB）

  • 测试选项

    • ThreadGroup
      • 线程数：表示启动多少个用户；
      • Ramp-Up：启动所有线程的时间；
      • 循环次数：每个用户执行多少次配置的请求；
      • 调度器：所有线程都到达后，持续的时间；
    • HTTP 属性：
      • 方法：Get
      • 地址：8.137.169.217:8081
      • URL：/sylar/xx 和 /
      • 连接超时：3s
      • 响应超时：10s

  • 阶段测试

    • 协程服务器
      • 打开日志
        • 1000 线程
          image-20260329200153913
        • 2000 线程
          image-20260329200637010
        • 5000 线程
          image-20260329201205644
        • 10000 线程
          image-20260329201538556
      • 关日志

        • 1000 线程
          image-20260329205415077

        • 2000 线程

    • muduo 网络库
      • 1000 线程
        image-20260329203013113

思路解析

针对 开日志 的情况下：

  • 1000 线程的吞吐量大概是 2700/sec，平均响应时间是 301 ms，错误率是 0。

    这说明系统现在是 健康的。

  • 2000 线程的吞吐量大概是 2863.9/sec，平均响应时间增加到 607 ms，错误率依旧是 0。

    吞吐只比 1000 线程多了一点，但延迟几乎翻倍。说明系统已经开始接近瓶颈。

  • 5000 线程的吞吐量大概是 2804.1/sec，平均响应到达了明显的 1324 ms，错误率仍然为 0。

    吞吐没继续涨，反而下降，说明已经进入排队区了

  • 10000 线程的吞吐量大概是 3111.7/sec，平均响应到达了惊人的 2211ms，错误率到达了 11.91%。

    这里表面吞吐变高了，但这是 “带错误” 的吞吐。

    成功吞吐量：3111.7 × (1 - 11.91%) ≈ 2741 req/s。

    10000 线程并没有真正提升有效处理能力，只是把系统压进了高延迟、高失败的失稳区。

结论

  协程服务器在开日志场景下：

  • 最佳稳定区间：大约 1000~2000 线程；
  • 稳定吞吐上限：大约 2800 req/s；
  • 5000 线程后：主要是在排队，不是在提升处理能力；
  • 10000 线程：已经超过稳定承载能力；

针对 关日志 的情况下：

  • 1000 线程的吞吐量：3461/sec，平均响应时间：241 ms，中位数：21ms，错误率：0.79%，P99：7099 ms；

和 “开日志，1000 线程” 相比：

  • 优点
    • 吞吐量：2741 → 3461，提升约 26.3%；
    • 平均响应：301ms → 241ms，下降约 20%；
    • 意义：
      • 日志确实是当前系统里的一个重开销点。
  • 缺点
    • 中位数只有 21ms
    • 但 P95 到了 895 ms
    • P99 到了 7099 ms
    • 还有 0.79% 错误率
    • 意义：
      • 系统不是 “整体都慢”，而是 大多数请求很快，但有一小部分请求会突然卡很久，甚至失败。
    • 问题可能存在的点：
      • 每个线程的负载不均；
      • 出现了 CPU 计算型任务；

muduo 网络库对比

  使用 关日志的协程服务器 对比：

  • 吞吐量更高：3461 > 3055
  • 平均响应更低：241 < 270
  • 中位数更低：21 < 50
  • 但错误率更高：0.79% > 0.09%
  • P99 更差：7099 > 2369

  这表明：“协程服务器主路径性能” 上已经不弱 muduo，甚至在 吞吐 和平均响应 上超过了 muduo；但在 高压下 的 尾延迟控制 和 稳定性 上，muduo 还是更稳。

  • 框架主路径优化具有有潜力；
  • 但高并发下的协程调度、公平性、排队控制、超时控制 还要加强；

框架优势及使用场景

优势场景

  • 高并发、IO 密集、等待时间长的业务
    • 相关场景：
      • 大量连接长期在线，但大部分时间都在等事件；
      • 需要频繁访问 Redis / MySQL / HTTP 上游的服务返回；
    • 原因：
      • 一个请求里会有很多 “等” 的时间，比如等 socket 可读、等定时器、等上游返回;
      • 协程可以在 等待时 主动让出执行权，并且 同一个线程能挂很多个协程，不需要一个连接绑一个线程
  • 业务流程比较复杂、串行步骤很多 的场景
    • 相关场景：
      • 比如一个请求要做：解析请求、查缓存、缓存没有则查数据库、调另一个 HTTP 服务、然后拼装响应；
      • 原因：
        • 代码可以写得像同步逻辑一样；
        • 调用链更直；
        • 业务越复杂、链路越长、等待点越多，协程风格越容易体现优势。

劣势场景

  • CPU 密集型业务
    • 相关场景：
      • 大量计算
      • 编解码
      • 加解密
      • 复杂算法
    • 原因：
      • CPU 拉满时，协程不会让算力变多，一个线程还是只会执行这一个任务；
      • 这种场景下，真正关键的是：利用多核的优势，将任务拆分，使用线程池策略；
  • 纯网络收发
    • 相关场景：
      • echo server
      • 简单 HTTP 静态返回
    • 原因：
      • 因为这类 请求链路 更短，几乎没有大量的 阻塞等待点，主要工作就是 “收包、处理、回包”。
      • 此时，协程调度、上下文切换、hook 机制以及额外的运行时管理，反而会带来一定开销。
      • muduo 这类基于 Reactor 模型的网络库路径更短，整体实现也更加直接，通常能够获得更稳定的尾延迟表现。