转载自：http://hi.baidu.com/yancncen/blog/item/b43bf4fee7c7c4385d6008de.html
最近，看了几个开源代码的server框架，有了一些自己的想法，把它记下来。
针对server要求高性能的同时还需要稳定性的特点，有了这样一个构思，建立一个EPOLL+多进程+线程池的server框架，暂且叫它emptyServer(e:epoll,m:muti,p:process,t:thread,y:ycc.哈哈)。
考虑的出发点如下：[......]
epoll和select是Linux中提供的两种不同模型，epoll的并发性要好于select，那么究竟能好多少呢？我用前两天实现的Echo Server的epoll和select版本做了测试。
首先是非并发情况，就是一个Request完成后再下一个。
我的测试环境，均本地网络，CPU P8600 2.4G 非节能模式，buffer均为16字节，发送的测试数据为30字节左右。
epoll
5k 0.336841 0.341372 0.327373 0.309983 0.348396
10w[......]
关于“惊群现象”：在阻塞模型中，各进程分别通过accept阻塞，等待连接到达，当一个连接到达时，所有的进程都会被唤醒，但只有其中一个进程可以成功accept该连接，其余的则继续投入睡眠，这就是所谓的惊群现象，转载的这篇文章很好的对Lighttpd进行了测试，并分析了惊群现象。模拟实现了epoll+prefox()模型。[......]
epoll是Kernel 2.6后新加入的事件机制，在高并发条件下，远优于select.
用个硬件中的例子吧，可能不太恰当：epoll相当于I／O中断（有的时候才相应），而select相当于轮询（总要反复查询）。
其实epoll比slect好用很多，主要一下几个用法。
struct epoll_event ; epoll事件体，事件发生时候你可以得到一个它。其中epoll_event.data.fd可以存储关联的句柄，epoll_event.event是监听标志，常用的有EPOLLIN （有数据[......]