WSL2中C+++epoll实现的HTTP服务器性能是否符合预期？

服务器实现与环境 #

• 运行环境：WSL2 Ubuntu
• 实现方式：C++ + epoll，非阻塞套接字架构
• 线程模型：主线程通过epoll_wait获取事件并放入队列，10个工作线程负责读写处理（暂不解析请求，直接返回字符数组）
• 设备配置：12代Intel Core i7-1255U、16GB内存、Windows 11 Pro 23H2

压测配置（artillery脚本） #

config:
  target: http://127.0.0.1:8086
  phases:
    - duration: 1
      arrivalRate: 10010
      name: Sustained peak load
  plugins:
    apdex: {}
  apdex:
    threshold: 100

scenarios:
  - flow:
      - loop:
        - get:
            url: "/"
        count: 40

压测结果 #

All VUs finished. Total time: 31 seconds

--------------------------------
Summary report @ 14:22:39(-0800)
--------------------------------

apdex.frustrated: .............................................................. 0
apdex.satisfied: ............................................................... 397875
apdex.tolerated: ............................................................... 2525
http.codes.200: ................................................................ 400400
http.downloaded_bytes: ......................................................... 86486400
http.request_rate: ............................................................. 14877/sec
http.requests: ................................................................. 400400
http.response_time:
  min: ......................................................................... 0
  max: ......................................................................... 300
  mean: ........................................................................ 29.4
  median: ...................................................................... 26.8
  p95: ......................................................................... 48.9
  p99: ......................................................................... 80.6
http.responses: ................................................................ 400400
vusers.completed: .............................................................. 10010
vusers.created: ................................................................ 10010
vusers.created_by_name.0: ...................................................... 10010
vusers.failed: ................................................................. 0
vusers.session_length:
  min: ......................................................................... 175.2
  max: ......................................................................... 2414.5
  mean: ........................................................................ 1230.5
  median: ...................................................................... 1176.4
  p95: ......................................................................... 1720.2
  p99: ......................................................................... 2101.1

Apdex score: 0.996846903096903 (excellent)

疑问 #

当前性能是否为epoll正确实现下的正常水平？还是远低于预期，说明存在实现问题？若需排查，可提供完整代码。

分析与结论 #

从压测数据来看，这个表现在WSL2环境下属于正常偏优的水平，但原生Linux环境下还有提升空间，具体分析：

1. 核心指标合理性

• 14877请求/秒的吞吐量：WSL2的网络虚拟化会带来一定性能损耗，这个数值对于仅返回固定字符的简易HTTP服务器来说是合理的。原生Linux下同类优化后的实现通常能达到20k-50k+请求/秒，但WSL2的损耗会拉低这个上限。
• Apdex得分0.997、0失败请求、p99响应时间80.6ms：说明服务稳定性极佳，没有出现严重阻塞或资源耗尽问题，epoll的基础实现逻辑是正确的。

2. 可优化方向（若追求更高性能）

• 事件队列优化：如果用的是互斥锁保护的队列，高并发下锁竞争会成为瓶颈，可替换为无锁队列。
• epoll模式检查：确认是否启用了EPOLLET（边缘触发），边缘触发能减少事件重复触发，提升处理效率。
• 套接字调优：开启TCP_NODELAY、调整套接字缓冲区大小，降低TCP层面的延迟。
• 线程数调整：i7-1255U有4大核+8小核，10个工作线程的配置基本合理，但可尝试匹配核心数（比如8-12个），避免过多上下文切换。
• 内存复用：避免每次响应都分配新的字符数组，复用预分配的内存块减少开销。

3. 潜在实现问题排查点

如果怀疑实现有隐性问题，可重点检查：

• 是否正确处理非阻塞套接字的EAGAIN/EWOULDBLOCK错误，防止线程阻塞在读写操作上。
• epoll事件注册是否正确：比如事件类型（EPOLLIN/EPOLLOUT）是否按需注册，是否存在重复注册同一套接字的情况。
• 主线程是否存在不必要的阻塞：比如epoll_wait超时设置是否合理，事件入队逻辑是否高效。

提供完整代码可进一步定位具体优化点。

内容的提问来源于stack exchange，提问作者1024k