nginx为什么比Apache支持高并发？？？
首先，先看一下各自使用的IO模型。
Apache使用的是select模型，该模型特点如下：
1、每个连接对应一个描述。select模型受限于 FD_SETSIZE（即进程最大打开的描述符数），linux2.6.35为1024,实际上linux每个进程所能打开描数字的个数仅受限于内存大小，然而在设计select的系统调用时，却是参考FD_SETSIZE的值。可通过重新编译内核更改此值，但不能根治此问题，对于百万级的用户连接请求即便增加相应进程数，仍显得杯水车薪。
2、select每次都会扫描一个文件描述符的集合，这个集合的大小是作为select第一个参数传入的值。但是每个进程所能打开文件描述符若是增加了，扫描的效率也将减小。
3、内核到用户空间，采用内存复制方式传递信息。
nginx使用的是epoll模型，该模型特点如下：
1、无文件描述字大小限制仅与内存大小相关。
2、epoll返回时已经明确的知道哪个socket fd发生了什么事件，不用像select那样再一个个比对。
3、内核到用户空间，采用共享内存方式传递消息。
其次，看一下各自的优势。
Apache的优点：
1、rewrite ，比nginx 的rewrite 强大；
2、模块超多，基本想到的都可以找到；
3、bug少 ，nginx的bug相对Apache较多；
4、超稳定，最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程。
nginx的优点：
1、轻量级，同样起web 服务，比apache 占用更少的内存及资源；
2、抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能；
3、高度模块化的设计，编写模块相对简单；
4、社区活跃，各种高性能模块发布迅速。
最后，epoll相对select的优点总结如下：
1、select的句柄数目受限，在linux/posix_types.h头文件有这样的声明：#define __FD_SETSIZE 1024 表示select最多同时监听1024个fd。而epoll没有，它的限制是最大的打开文件句柄数目。
2、epoll的最大好处是不会随着FD的数目增长而降低效率，在selec中采用轮询处理，其中的数据结构类似一个数组的数据结构，而epoll是维护一个队列，直接看队列是不是空就可以了。epoll只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数（把这个句柄加入队列），其他idle状态句柄则不会，在这点上，epoll实现了一个"伪"AIO。但是如果绝大部分的I/O都是“活跃的”，每个I/O端口使用率很高的话，epoll效率不一定比select高（可能是要维护队列复杂）。
3、使用mmap加速内核与用户空间的消息传递。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。
个人拙见，如有错误，欢迎指正~O(∩_∩)O
.Nginx的工作原理：
Nginx并不会为每一个的web请求创建新的进程，相反，管理员可以配置Nginx主进程的工作进程的数量（一个常见的做法是为每一个CPU配置一个工作进程）。所有这些进程都是单线程的。
每一个工作进程可以处理数千个并发的请求。它通过一个线程来异步非阻塞的完成了这些工作（epoll），而没有使用多线程的编程模型。
nginx的优势：
采用单线程来异步非阻塞处理请求，不会为每个请求分配cpu和内存资源，节省了大量资源，同时也减少了大量的CPU的上下文切换。所以才使得Nginx支持更高的并发。
扫一扫
642
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
