Boost Asio应用高吞吐量延迟优化：busy-polling最优配置值咨询

是否需要设置/proc/sys/net/core/busy_poll和busy_read？ #

在CPU资源充足的前提下，非常有必要。

你当前已经在应用层采用了多io_context+忙循环poll()的优化，但这类优化只覆盖了用户态的调度延迟，内核态的数据包交付延迟依然存在：传统Linux网络栈中，当数据包到达时，内核会通过中断唤醒阻塞的用户态线程，这个唤醒过程在高吞吐量场景下会产生显著的累积延迟。

busy_poll和busy_read是Linux内核提供的忙轮询参数，作用是让内核在用户态线程发起IO操作时，主动在一个小循环内轮询数据包，而非立即休眠等待中断。这正好匹配你当前的忙循环poll()模式，能直接跳过线程唤醒的开销，将数据包更快地从内核态交付到用户态，非常适合行情数据这种对延迟敏感的场景。

最优配置值是多少？ #

没有绝对的“最优值”，需要结合你的硬件架构、负载压力进行调优，但可以参考以下规则：

• 基础参考范围：建议从100到1000之间开始测试。这个数值代表内核在轮询时的循环次数，x86架构下大概每100次循环对应1微秒左右的轮询时间。
• 调优步骤：
  1. 先设置保守值（如100），测试延迟指标和CPU占用率；
  2. 逐步增大数值（每次增加100-200），直到延迟不再明显降低，同时CPU占用仍在可接受范围内（你CPU充足，可适当放宽上限）；
  3. 若你的应用已绑定到独占CPU核心（无其他进程共享），可以尝试调高到500-1000，进一步降低延迟。
• 注意事项：数值过大可能导致内核空转占用过多CPU，但在你CPU资源充足的场景下，这个副作用可以忽略。

额外优化建议（针对当前场景） #

除了内核参数调整，你还可以从以下方向进一步降低延迟：

• CPU绑核：将每个io_context对应的线程绑定到固定CPU核心，避免线程调度带来的上下文切换开销；
• SSL层优化：启用TLS 1.3减少握手延迟，开启SSL会话复用，优先选择支持硬件加速的加密算法（如AES-NI）；
• TCP参数调整：开启tcp_low_latency=1和tcp_nodelay=1，调大net.core.rmem_max和net.core.wmem_max以避免接收/发送缓冲区溢出；
• 用户态缓冲优化：尽量减少WebSocket帧处理过程中的内存拷贝，使用Asio的零拷贝特性（如直接使用mutable_buffer映射内核缓冲区）。

内容的提问来源于stack exchange，提问作者Eduard Rostomyan