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

针对第一篇文章里面，作者提到：“需要注意的是，如果仅仅的采用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复用实现异步实现高并发的方式编程复杂度很高不易控制。epoll_wait多线程当然，也有认为多线程的同步控制其编程复杂度也很高不易控制所以反对之。

平时要加强 识读图表能力的训练，善于从图、表提供数据的处理过程中理解试题，做出正确结论。下面是我的出来的实验数据，由于测试很简单，有个带法宝的天宫就能轻易得出这个结论，所以就不传实验录像了。还有本清华吴庆余编的《基础生命科学》内容与普生相仿，要学会取舍：很抱怨动生难学，糖类脂肪也可适当参考一下。

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

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

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

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

当核内既支持进程也支持线程时，就可以实现线程-进程的'多对多'模型，即一个进程的某个线程由核内调度，而同时它也可以作为用户级线程池的调度者，选择合适的用户级线程在其空间中运行。线程在进程的地址空间中，一个进程的中可执行多个线程，每个线程是一个控制流（负责一件事情），多线程的控制流程可以长期并存，操作系统会在各线程之间调度和切换，就像在多个进程之间调度和切换一样。这里的工作主要分为两大块：一块是避免线程切换调度，降低锁竞争和无锁化，另外一块是采用用户态协议栈+dpdk来将run-to-completion进行到底。

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

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-97297-1.html