今天偶然看到两篇关于讨论epoll与高性能问题的文章，文章均颇为争议，下面是两篇文章和讨论的地址：

    http://guanzhongdaoke-gmail-com.iteye.com/blog/189005

    http://bbs.linuxtone.org/thread-3164-1-1.html

 

    针对第一篇文章里面，作者提到：“需要注意的是，如果仅仅的采用epoll来处理网络服务器的话，感觉性能不会提高太大，毕竟io的处理相对于epoll或者poll的检测来说，时间消耗是比较多的。这个话说得可能比较的绕口，简单说就是你每次的epoll_wait所花费的时间，相对于你得到事件后所作的read,write==花费的时间要少狠多”，首先我们要明确如下一点：

    1) I/O多路复用技术，不管是select/poll也好，还是epoll也好，对于read/write和业务逻辑，不论采用什么模型，这三者之间都不会有任何区别。那我们为什么说epoll好？说epoll好是相对于select和poll，而且其更好是源自于起事件通知机制，并不是epoll_wait所花费的时间与读写费时的比较。epoll因为采用了回调通知机制，相比于select和epoll的现行扫描和频繁的内存拷贝操作而高效。但epoll的高效也是有适用场景的，其更适合于hold大量连接，但连接并不是特别活跃的场景。相比于select、poll，由于epoll省却了频繁的线性扫描和内存拷贝，故而效率凸显；但对于I/O频繁（大量数据传输是否可认为I/O频繁呢？）场景，epoll或者说事件驱动的机制，其高效并不明显

  2)如上说明了epoll最被人称道的高效的原因，那是在和select与poll的对比之下，现在讨论忽略epoll和另外两者的不同之处，I/O多路复用机制的高效根源。这三种机制，目的均在于减少对I/O操作的等待，使进程不被阻塞于I/O，更快的响应用户请求，提高交互体验。其实是将I/O分片，这种思想其实个人感觉有点操作系统时间片轮转机制的影子，不过这里是将I/O分片而不是CPU时间分片，将长耗时的I/O等待划分为多片，将I/O等待时间利用到响应用户的时间上，增大并发度。

    讨论了I/O复用的好处，下一个争议点是要不要在epoll(个人认为select和poll也一样)的同时使用多线程，反对意见者认为多线程需要加锁开销和切换开销，持支持意见这认为多线程能增大吞吐并且用I/O复用实现异步实现高并发的方式编程复杂度很高不易控制。当然，也有认为多线程的同步控制其编程复杂度也很高不易控制所以反对之。

    对于这一块，我也不能轻易下结论，或者这本来就是个见仁见智的问题。不过在此我想写下一些我所理解或者想到的东西，做个参考，适当取舍，备忘。

    I/O复用，将I/O等待分片，已可实现初步的高并发，我们说过，epoll在I/O不活跃的时候性能不错，我们就假设这种场景，ok，现在已经够高效了，其实epoll已经完成了自己的使命了，后端多线程单线程神马的和epoll的关系不是特别大的说。

   一，使用单核CPU，这时候用单线程和多线程的区别是什么？优缺点分别是？

            单核CPU为什么要使用多线程呢？可能是为了利用CPU时间分片的好处增大交互体验，对于本身的任务处理并不能加速，也有可能减少I/O等待所带来的交互体验差（此处我们已经通过epoll解决了这个问题，当然不排除还要使用磁盘I/O，其实也可能使用epoll突破）；但是这样带来的负面效果是线程切换所引起的开销；当然还有可能存在加锁的开销

   二，多核环境下，使用单线程多线程的区别？优缺点

            很明显，多核环境下的单线程，无法利用到多核优势，此外，在多核环境下，如果线程设计合理，将任务均分到不同的核，可充分利用多核优势，并且不会导致过多的线程切换带来的性能开销（因为多核情况下，每个核拥有自己独立的运行队列，每个核上均存在自己的调度），此时单进程唯一的有点将是更少的锁争用

 

 

    暂时想到的就这么多……不知道准确否，至少在思考了