由nginx和apche性能差别延伸的知识

之前被人问到一个问题，nginx和apache在高并发情况下，哪个好？
答：nginx
再问：为什么？
答：。。。。因为apche支持的模块多，so。。。。balabal


肯定不对了，但是也不知道具体是什么原因，后来回头查阅资料了，才知道原来是实现机制的不同导致的。具体为：
nginx是的是epoll模式的非堵塞式的事件响应
apache使用是select的是堵塞式的事件相应


但是什么epoll，什么是select？不能下次有人问到又瞎扯了，所以进一步又查了下相关资料。虽然基本算是明白咋回事了，但是如果要说清楚还得用个实例才能描述。


select模式场景：
古代的客栈没有电话，为了让房客需要服务时不用去服务大厅就能通知客房总管，客栈为每个房间都提供了一个拉线，如果房客需要服务时直接拉一下拉线，则服务大厅里的铃铛就会响起【同时夹住铃铛的总拉线，防止其他人或者反复拉线】，此时就能知道有房客需要服务了，客房总管就会派伙计去每个房间轮询问房客是否叫了服务，直到找到需要需要的房客，然后再询问需要的具体服务，最后伙计回来告知客房总管，客房总管通知相关服务部门为该房间的房客进行服务，完事后才松开那个被夹住的铃铛总拉线，等待其他房客叫服务。


epoll模式场景：
现代酒店安装了电话后【假设只有一台被叫电话】，房客有需求后就可以直接打电话到总台，并且同时告诉总台是哪个房间的客人，叫了什么服务。总台直接通知相关服务部门直接对其进行服务，电话结束后就可以开始等待下个房客叫服务了。


这下epoll和select模式哪个更有效率就一目了然了。此外还有扩展知识就是cgi和fastcgi模式的web服务搭建形式，因为这2个都是会和apache和nginx服务器结合使用的。
那么到底cgi和fastcgi的区别是什么呢？


cgi模式时有web请求时才开始启动cgi进程为其服务，完事后关闭该进程；再次有请求时重来一次，同时有多个请求时同时起多个进程，具体可以启动的进程数没有固定上限，主要看cpu、mem的情况。


cgi模式：
无请求状态：无常驻cgi进程
有请求状态：新起cgi进程，完事退出cgi进程
再次有请求状态：再次新起cgi进程。。。
同时有多个请求状态：同时新起多个cgi进程


fastcgi模式在web服务启动时就启动了N个cgi进程，具体数目可配置，这些进程再web服务过程中一直常驻内存，除非关闭web服务器；有请求来了会连接其中一个cgi进程并提交任务，完事了关闭和cgi进程的连接，下次再有请求时重新连接一次，同时有多个请求时同时连接多个cgi，但是这里会有上限和链接超时时间。【当然可以提前设置一个最大的cgi进程数】


fastcgi模式：
无请求状态：N个cgi常驻进程
有请求状态：不新起cgi进程，连接已有的cgi进程，完事关闭cgi连接
再次请求状态：再次连接cgi进程。。。
同时有多个请求状态：同时连接多个cgi进程


所以cgi和fastcgi的区别就在于一个需要反复的新起、退出进程，一个是常驻进程；而新起进程是非常耗资源的和时间的操作，甚至超过完成请求任务本身了，所以孰优孰劣一目了然。。