为什么Nginx的性能要比Apache高很多？

apache和nginx网络I/O模型不同
apache->select
nginx->epoll (主要用这个)
select，epoll都是IO多路复用的机制。
I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。
但select，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，
也就是说这个读写过程是阻塞的
目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。
下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。
select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。
而epoll版宿管大妈会先记下每位同学的房间号，
你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。
如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。
同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了。  
select模型：（apache使用，由于受模块等限制，用的不多）
单个进程能够监视的文件描述符的数量存在最大限制
select()所维护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长
由于网络响应时间的延迟使得大量TCP连接处于非活跃状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会造成一定的开销
poll：poll是unix沿用select自己重新实现了一遍，唯一解决的问题是poll 没有最大文件描述符数量的限制
epoll模型：（nginx使用）
epoll带来了两个优势，大幅度提升了性能：
基于事件的就绪通知方式 ，select/poll方式，进程只有在调用一定的方法后，内核才会对所有监视的文件描述符进行扫描，而epoll事件通过epoll_ctl()注册一个文件描述符，
一旦某个文件描述符就绪时，内核会采用类似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会得到通知
调用一次epoll_wait()获得就绪文件描述符时，返回的并不是实际的描述符，而是一个代表就绪描述符数量的值，拿到这些值去epoll指定的一个数组中依次取得相应数量的文件描述符即可，
这里使用内存映射（mmap）技术， 避免了复制大量文件描述符带来的开销
当然epoll也有一定的局限性， epoll只有Linux2.6才有实现 ，而其他平台都没有，这和apache这种优秀的跨平台服务器，显然是有些背道而驰了。
简单来说epoll是select的升级版，单进程管理的文件描述符没有最大限制。但epoll只有linux平台可使用。作为跨平台的Apache没有使用。

apache和nginx并发策略不同：

最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；
nginx是异步的，采用单线程来异步非阻塞处理请求，不会为每个请求分配cpu和内存资源，
节省了大量资源，同时也减少了大量的CPU的上下文切换。多个连接（万级别）可以对应一个进程，所以才使得Nginx支持更高的并发，