epoll 与 select 对于极少量的连接

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

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

现在，随着最近切换到 epoll，我注意到应用程序的性能下降了，我实际上很惊讶，并期望性能上升或保持相同。我尝试查看其他各个部分，这是唯一已更改的代码。

如果 epoll 用于非常少量的套接字（如 1 或 2），那么它在速度方面是否会造成性能损失？

另一件值得注意的事情是，我在同一个机器（8 个 cpu 核心）上运行大约 125 个这样的进程。 这可能是太多进程在同一台机器上执行 epoll_wait 的情况，当我使用 select 时，此设置类似。

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

关于我应该更多地寻找问题来确定问题的任何想法/指示。

虽然增加的绝对延迟非常小，平均为 1 毫秒，但这是一个实时系统，这种延迟通常是不可接受的。

Thanks

Hi,

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

thanks

从它的声音来看，吞吐量可能不受影响epoll() vs select()，但是您发现各个请求中存在额外的延迟，这似乎与使用epoll().

我认为在只观看一两个插座的情况下，epoll()应该表现得很像select(). epoll()当您观看更多描述符时，应该会线性缩放，而select()扩展性很差（甚至可能对#/描述符有硬性限制）。所以不是那样的epoll()对少量描述符有惩罚，但它失去了性能优势select()在这种情况下。

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