我一直在使用select来处理连接，最近我们的套接字库发生了变化，并且选择被epoll替换为linux平台。
我的应用程序架构是这样的，我只在一个线程中创建一个或最多2个套接字连接和epoll / select。
现在随着最近切换到epoll我发现应用程序的性能已经消失，我实际上感到惊讶，并且期待性能上升或者恢复相同。我尝试查看各种其他部分，这是唯一已经改变的代码。
如果用于非常少量的套接字（如1或2），epoll的速度是否会降低性能。 另外需要注意的是，我在同一个盒子（8个cpu核心）上运行了大约125个这样的进程。 可能是因为太多进程在同一台机器上运行epoll_wait，当我使用select时，这个设置类似。我注意到盒子上的平均负载要高得多，但cpu的使用率却相同，这让我觉得在I / O上花费的时间更多，而且与epoll相关的变化也是如此。
关于我应该更多地查明问题的任何想法/指示。
尽管绝对延迟增加的幅度非常小，平均为1毫秒，但这是一个实时系统，这种延迟通常是不可接受的。
由于
您好，
在最新的findinds上更新这个问题，除了从select切换到epoll之外我发现了另一个相关变化，早期超时选择是10毫秒，但epoll的方式超时比以前小（比如1微...），可以在select或epoll中设置太低的超时会导致性能下降吗？
感谢
答案 0 :(得分：3)
从它的声音来看，epoll()与select()的吞吐量可能不受影响，但您发现个别请求中的额外延迟似乎与使用epoll()有关
我认为在仅观看一个或两个套接字的情况下，epoll()应该像select()那样执行。 epoll()应该在观看更多描述符时进行线性缩放，而select()则会严重缩放（并且甚至可能对＃/描述符有严格的限制）。因此epoll()并不会对少量描述符造成惩罚，但在这种情况下，它会超过select()的性能优势。
您可以更改代码，以便轻松返回＆amp;两个事件通知机制之间？获取有关性能差异的更多数据。如果你最终发现select()延迟时间较短＆amp;在你的情况下相同的吞吐量，然后我会毫不犹豫地切换回“旧的和已弃用的”API :)对我来说，如果你测量这个特定代码更改的性能差异，这是相当确定的。也许先前对epoll()与select()的测试主要关注单个请求的吞吐量与延迟？