epoll vs选择极少数的连接

我一直在使用select来处理连接，最近我们的套接字库发生了变化，select被epoll for linux平台所取代。epoll vs选择极少数的连接

我的应用程序体系结构是这样的，我做只有一个或最多2套接字连接和epoll的/在一个单独的线程选择他们。

现已与最近交换机EPOLL我注意到应用的是性能diminshed，我其实感到惊讶和期待性能上还是reamin相同。我试着寻找各种其他部分，这是改变了的唯一代码。

如果用于极少数插座（如1或2），epoll在速度方面会有性能损失。

另外还有一件事要注意，我在同一个盒子上运行了125个这样的进程（8个CPU核心）。可能是这种情况，太多的进程在同一台机器上做epoll_wait，这个设置与我使用select时类似。

我注意到框，平均负载要高得多，但CPU使用率是这让我觉得更多的时间花费在I/O，并从epoll的相关变化probaly未来不太一样。

任何想法/指示什么我应该看看更多以确定问题。

虽然绝对延迟时间增加是相当小的，如平均1毫秒，但是这是一个实时的系统，而这种等待时间一般都unaccpetable。

感谢

嗨，

更新的最新findinds这个问题，除了从选择到EPOLL切换我发现了另一个相关的变化，早期的超时时间选择在10个米利斯但epoll的超时的方式是这样比以前更小（比如1微米..），可以设置太低的select或epoll超时结果导致性能下降？

感谢

来源

2011-11-24 user424060

相关问题在http://stackoverflow.com/questions/4093185/whats-the-difference-between-epoll-poll-threadpool –

可能的重复[是否有任何益处使用epoll与少量的文件描述符？]（http://stackoverflow.com/questions/8597452/is-there-any-benefit-to-using-epoll-with-a-very-small-number-of-file-descriptors） – gavv

从它的声音，吞吐量可能受到影响与epoll() VS select()，但是你发现的，这似乎是与使用的epoll()个别要求额外的延迟。

我认为在只看一个或两个插座的情况下，epoll()应该表现得很像select()。当您观看更多描述符时，epoll()应该按比例线性缩放，而select()缩放很差（&甚至可能对＃/描述符有严格的限制）。所以这并不是说epoll()对一小部分描述符有一定的惩罚，但是在这种情况下，它的性能优势超过select()。

您可以更改代码，以便您可以轻松地回去&来回两个事件通知机制之间？获取有关性能差异的更多数据。如果您确凿发现select()具有更短的延迟&相同的吞吐量在您的情况，然后我只是切换回“老&弃用” API毫不犹豫:)对我来说，这是相当确凿的，如果你测量从这个特定代码的性能差异更改。也许之前对epoll()与select()的测试关注于吞吐量与个别请求的延迟？

来源

2011-11-24 04:11:46

epoll vs选择极少数的连接

回答

相关问题