【转】再论epoll

原文地址：http://hi.baidu.com/netpet/blog/item/bebc3ba8d671a3b7ca130cf5.html
学习时间的过程终会有反复，其中也包括一些错误，上午对于前一篇关于epoll的文章进行了增改，下午就觉得有些不妥，重新编辑感觉不太容易剥楼错误，现在有些新的变化在这里重新论述。

上午说的在epoll里面进行耗时任务的时候做一个任务调度器（比如当服务器连接外部资源），这说明我只了解了epoll的一部份，没有充分认识到它的普遍意义的应用，其实对于外部连接epoll可以作为服务器端的任务调度器使用，但是它同样适用于主动式连接的socket，换言之，如果服务器需要连接外部socket资源也同样可以将它连接的道德socket fd加入epoll的监视，这样epoll的调度就更有广泛了，所有需要socklet交互的部分都可以交由epoll，然后他负责监制EPOLLIN和EPOLLOUT两个事件，这两个事件的组合多次利用就可以构成整个服务事件驱动机制，所以我上午说的任务调度其也是多余的。

     有人可能想了，那么对于多核服务器不久没有任何优势了么？我的设想是这样的，先在单线程的模型上完成开发，如果想扩展到多核，可以在epoll的下面再次构建一个多线程的任务调度器，也就是将epoll检测到的事件再次保存到一个结构体，用多线程去读取并处理事件，这样不会影响大部分的代码，真正的程序不是直接响应epoll事件，而是在新的任务调度器下面统一处理epoll事件的副本，这样就有epoll主动事件驱动调用变成了异步的，多线程并行执行的模型，但是每个连接同一时间也只有一个线程在处理，现在还没有经过实际测试，不确信对于性能的影响如何。

    如果所有实际的处理过程暂用cpu很短那么加上我上面设计的一层任务调度就是多余的，因为所以的问题都会集中体现在网络上，这不是服务器所能解决的，如果网络快到了事件在等待任务，那么这种模型才有可能有较好的表现，所以是否应用还是要看具体的服务内容，事实证明单线程已经处理的足够快了，每秒1万页的处理速度能满足绝大多数的需求，所以就设计而言，关键问题还是要解决瓶颈，而不是将所有想到的好技术都应用上，瓶颈可能还没有得到解决，反而更加浪费cpu资源。

    所以我觉决定还是全部以epoll驱动去做这个web架构，毕竟nginx等都有上佳的表现，这样看来做个代理或者反项代理也是很容易的，还可以更加节约资源

    看了这么久才算对于nginx等处理模型有了个大致的了解，起初打算更改它的代码，后来发现太麻烦了，所以重新自己架构，走下来发现只要了解思路了具体的技术是很快的，不然看别人的代码太辛苦了