问题描述
我一直在使用select处理连接，最近我们的套接字库发生了变化，对于Linux平台，select被epoll取代了.
I have been using select to handle connections, recently there was a change an our socket library and select was replaced by epoll for linux platform.
我的应用程序体系结构使得我只能建立一个或最多2个套接字连接，并在单个线程中对它们进行epoll/select.
my application architecture is such that I make only one or at max 2 socket connections and epoll/select on them in a single thread.
现在，随着最近切换到epoll，我注意到应用程序的性能已经下降，我实际上感到很惊讶，并期待性能提高或提高.我尝试查看了其他各个部分，这是唯一已更改的代码.
now with recent switch to epoll i noticed that performance of application has diminshed, I was actually surprised and was expecting performance go up or reamin same. I tried looking at various other parts and this is the only peice of code that has changed.
如果将epoll用于极少数的套接字(例如1或2)，会在速度方面造成性能损失.
does epoll have performance penalty in terms of speed if used for very small number of sockets (like 1 or 2).
另外要注意的是，我在同一个盒子(8个cpu内核)上运行了大约125个这样的进程.可能是因为太多进程在同一台机器上执行epoll_wait，当我使用select时，此设置是类似的.
also anoher thing to note that I run around 125 such processes on same box (8 cpu cores).could this be case that too many processes doing epoll_wait on same machine, this setup was similar when i was using select.
我在包装盒上注意到平均负载要高得多，但是cpu的使用率却完全相同，这使我认为更多的时间都花在了I/O上，并且很可能来自与epoll相关的更改.
i noticed on box that load average is much higher but cpu usage was quite the same which makes me think that more time is spend in I/O and probaly coming from epoll related changes.
关于我应该进一步查找问题的任何想法/指标.
any ideas/pointers on what should i look more to identify the problem.
尽管绝对延迟增加非常小，例如平均1毫秒，但这是一个实时系统，这种延迟通常是不可行的.
although absolute latency increased is quite small like average 1 millisec but this is a realtime system and this kind of latencies are generally unaccpetable.
谢谢
在最新的findinds上更新此问题，除了从select切换到epoll之外，我还发现了另一个相关的变化，select的早期超时为10毫秒，而epoll的超时时间则比以前小得多(例如1 micro ..)在select或epoll中设置的超时时间过低会导致性能下降吗?
Updating this question on latest findinds, apart from switching from select to epoll I found another relate change, earlier timeout with select was 10 millis but with epoll the way timeout is way smaller than before (like 1 micro..), can setting too low timeout in select or epoll result on decreased performance in anyway?
谢谢
推荐答案
从听起来来看，吞吐量可能不受epoll()和select()的影响，但是您发现单个请求中的额外延迟似乎是与epoll()的使用有关.
From the sounds of it, throughput may be unaffected with epoll() vs select(), but you're finding extra latency in individual requests that seems to be related to the use of epoll().
我认为在仅观察一个或两个套接字的情况下，epoll()的性能应与select()相似.当您观看更多描述符时，epoll()应该线性缩放，而select()则缩放严重(&#甚至对#/descriptor都有硬限制).因此，并不是epoll()对一小部分描述符会造成损失，但是在这种情况下，它失去了优于select()的性能优势.
I think that in the case of watching only one or two sockets, epoll() should perform much like select(). epoll() is supposed to scale linearly as you watch more descriptors, whereas select() scales badly (& may even have a hard limit on #/descriptors). So it's not that epoll() has a penalty for a small # of descriptors, but it loses its performance advantage over select() in this case.
您是否可以更改代码，以便轻松返回&两种事件通知机制之间有什么联系?获取有关性能差异的更多数据.如果您最终发现select()的延迟更短&；在您遇到相同的吞吐量的情况下，那么我会毫不犹豫地切换回旧的和已弃用的" API :)对我来说，如果您衡量此特定代码更改的性能差异，则是相当确定的.也许以前epoll()与select()的测试集中在吞吐量与单个请求的延迟之间?
Can you change the code so you can easily go back & forth between the two event notification mechanisms? Get more data about the performance difference. If you conclusively find that select() has less latency & same throughput in your situation, then I'd just switch back to the "old & deprecated" API without hesitation :) To me it's fairly conclusive if you measure a performance difference from this specific code change. Perhaps previous testing of epoll() versus select() has focused on throughput versus latency of individual requests?
这篇关于epoll与select的连接数量很少的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！