c++ - epoll vs select 用于非常少量的连接

Question

我一直使用 select 来处理连接，最近我们的套接字库发生了变化，select 被 linux 平台的 epoll 取代了。

我的应用程序架构是这样的，我只建立一个或最多 2 个套接字连接，并在单个线程中对它们进行 epoll/select。

现在最近切换到 epoll，我注意到应用程序的性能下降了，我真的很惊讶，并期待性能上升或保持不变。我尝试查看其他各个部分，这是唯一发生变化的代码。

如果用于非常少量的套接字(如 1 或 2)，epoll 是否会在速度方面造成性能损失。

另外需要注意的是，我在同一个盒子(8 个 CPU 内核)上运行了大约 125 个这样的进程。这可能是因为太多进程在同一台机器上执行 epoll_wait，这个设置与我使用 select 时类似。

我注意到 box 上的平均负载高得多，但 cpu 使用率完全相同，这让我认为更多的时间花在了 I/O 上，并且可能来自与 epoll 相关的更改。

关于我应该多看什么来确定问题的任何想法/指示。

虽然绝对延迟增加非常小，平均 1 毫秒，但这是一个实时系统，这种延迟通常是 Not Acceptable 。

谢谢

你好，

在最新的 findinds 上更新这个问题，除了从 select 切换到 epoll 我发现了另一个相关的变化，早期的 select 超时是 10 毫秒，但是 epoll 的超时方式比以前小得多(比如 1 micro..)，可以在 select 或 epoll 中设置太低的超时会导致性能下降吗？

谢谢

Answer 1

从它的声音来看，吞吐量可能不受 epoll() 与 select() 的影响，但您会发现个别请求中的额外延迟似乎是与 epoll() 的使用有关。

我认为在只观察一个或两个套接字的情况下，epoll() 的表现应该很像select()。 epoll() 应该在您观察更多描述符时线性缩放，而 select() 缩放很糟糕(甚至可能对 #/descriptors 有硬性限制)。所以并不是 epoll() 对少量描述符有惩罚，而是在这种情况下它失去了相对于 select() 的性能优势。

您能否更改代码以便轻松地在两种事件通知机制之间来回切换？获取有关性能差异的更多数据。如果您最终发现 select() 在您的情况下具有更短的延迟和相同的吞吐量，那么我会毫不犹豫地切换回“旧的和已弃用的”API :) 对我来说，如果您测量此特定代码更改的性能差异。也许以前对 epoll() 与 select() 的测试侧重于吞吐量与单个请求的延迟？