nginx VS apache/nginx是多进程工作

https://blog.csdn.net/xxb2008/article/details/42238557

http://tengine.taobao.org/book/chapter_2.html#connection  经典nginx探索

Nginx比较Apache：事件驱动适合于IO密集型服务，多进程或线程适合于CPU密集型服务

1）Nginx更主要是作为反向代理，而非Web服务器使用。其网络模式是事件驱动（select、poll、epoll）。
2）事件驱动的本质还是IO事件，应用程序在多个IO句柄间快速切换，实现所谓的异步IO。
3）事件驱动服务器，最适合做的就是这种IO密集型工作，如反向代理，它在客户端与WEB服务器之间起一个数据中转作用，纯粹是IO操作，自身并不涉及到复杂计算。
4）反向代理用事件驱动来做，显然更好，一个工作进程就可以run了，没有进程、线程管理的开销，CPU、内存消耗都小。
5）当然，Nginx也可以是多进程 + 事件驱动的模式，几个进程跑libevent，不需要Apache那样动辄数百的进程数。
6）Nginx处理静态文件效果也很好，那是因为静态文件本身也是磁盘IO操作，处理过程一样。至于说多少万的并发连接，这个毫无意义。我随手写个网络程序都能处理几万7）的并发，但如果大部分客户端阻塞在那里，就没什么价值。

再看看Apache或者Resin这类应用服务器，之所以称他们为应用服务器，是因为他们真的要跑具体的业务应用，如科学计算、图形图像、数据库读写等。它们很可能是CPU密集型的服务，事件驱动并不合适。

1）例如一个计算耗时2秒，那么这2秒就是完全阻塞的，什么event都没用。想想MySQL如果改成事件驱动会怎么样，一个大型的join或sort就会阻塞住所有客户端。
2）这个时候多进程或线程就体现出优势，每个进程各干各的事，互不阻塞和干扰。当然，现代CPU越来越快，单个计算阻塞的时间可能很小，但只要有阻塞，事件编程就毫无优势。所以进程、线程这类技术，并不会消失，而是与事件机制相辅相成，长期存在。

总结之，事件驱动适合于IO密集型服务，多进程或线程适合于CPU密集型服务，它们各有各的优势，并不存在谁取代谁的倾向。

问题1： Nginx采用worker进程来处理请求，一个worker进程只有一个主线程，那么有多少个worker子进程就能处理多少个并发，那么能够处理的并发数有限。概括的讲，Nginx如何实现高并发？
        回答1：采用异步非阻塞的事件处理机制。之所以能够并发处理大量的未处理完的请求，是通过异步非阻塞方式，由进程循环处理多个准备好的事件。以epoll为例，为准备好的事件都会放入epoll中，只要有事件准备好，就会进行处理。                   

问题2：何为异步非阻塞方式
        回答2：http://www.ibm.com/developerworks/cn/linux/l-async/

问题3：Nginx与Apache对于高并发处理上的区别。
        回答3：对于Apache，每个请求都会独占一个工作线程，当并发数到达几千时，就同时有几千的线程在处理请求了。这对于操作系统来说，占用的内存非常大，线程的上下文切换带来的cpu开销也很大，性能就难以上去，同时这些开销是完全没有意义的。

     对于Nginx来讲，一个进程只有一个主线程，通过异步非阻塞的事件处理机制，实现了循环处理多个准备好的事件，从而实现轻量级和高并发。

问题4：为何推荐worker的个数为cpu的个数？
        回答4：因为更多的worker数，只会导致进程相互竞争cpu资源，从而带来不必要的上下文切换

参考 http://tengine.taobao.org/book/chapter_2.html#connection 初探Nginx架构
--------------------- 
作者：xxb2008 
来源：CSDN 
原文：https://blog.csdn.net/xxb2008/article/details/42238557 
版权声明：本文为博主原创文章，转载请附上博文链接！