Nginx才短短几年，就拿下了Web服务器大壁江山，家喻户晓，Nginx在解决大并发动态申请方面，效率显著高于Httpd，甚至能轻松解决C10K问题。
在高并发连贯的状况下，Nginx是Apache服务器不错的替代品。Nginx同时也能够作为7层负载平衡服务器来应用。依据我的测试后果，Nginx + PHP(FastCGI) 能够接受3万以上的并发连接数，相当于等同环境下Apache的10倍。
一般来说，4GB内存的服务器+Apache（prefork模式）个别只能解决3000个并发连贯，因为它们将占用3GB以上的内存，还得为零碎预留1GB的内存。我已经就有两台Apache服务器，因为在配置文件中设置的MaxClients为4000，当Apache并发连接数达到3800时，导致服务器内存和Swap空间用满而解体。
而这台 Nginx + PHP(FastCGI) 服务器在3万并发连贯下，开启的10个Nginx过程耗费150M内存（15M*10=150M），开启的64个php-cgi过程耗费1280M内存（20M*64=1280M），加上零碎本身耗费的内存，总共耗费不到2GB内存。如果服务器内存较小，齐全能够只开启25个php-cgi过程，这样php-cgi耗费的总内存数才500M。
在3万并发连贯下，拜访Nginx+ PHP(FastCGI) 服务器的PHP程序，依然速度飞快。
为什么Nginx在解决高并发方面要优于httpd，咱们先从两种web服务器的工作原理以及工作模式说起。
一、Apache三种工作模式
咱们都晓得Apache有三种工作模块，别离为：prefork、worker、event。
- prefork： 多过程，每个申请用一个过程响应，这个过程会用到select机制来告诉。
- worker： 多线程，一个过程能够生成多个线程，每个线程响应一个申请，但告诉机制还是select不过能够承受更多的申请。
- event： 基于异步I/O模型，一个过程或线程，每个过程或线程响应多个用户申请，它是基于事件驱动（也就是epoll机制）实现的。
1、prefork的工作原理
如果不必“–with-mpm”显式指定某种MPM，prefork就是Unix平台上缺省的MPM。它所采纳的预派生子过程形式也是 Apache1.3中采纳的模式。
prefork自身并没有应用到线程，2.0版应用它是为了与1.3版放弃兼容性；另一方面，prefork用独自的子过程来解决不同的申请，过程之间是彼此独立的,这也使其成为最稳固的MPM之一。
2、worker的工作原理
绝对于prefork，worker是2.0版中全新的反对多线程和多过程混合模型的MPM。因为应用线程来解决，所以能够解决绝对海量的申请，而系统资源的开销要小于基于过程的服务器。
然而，worker也应用了多过程,每个过程又生成多个线程，以取得基于过程服务器的稳定性，这种MPM的工作方 式将是Apache2.0的发展趋势。
3、event 基于事件机制的个性
一个过程响应多个用户申请，利用callback机制，让套接字复用，申请过去后过程并不解决申请，而是间接交由其余机制来解决，通过epoll机制来告诉申请是否实现；在这个过程中，过程自身始终处于闲暇状态，能够始终接管用户申请。能够实现一个过程程响应多个用户申请。反对持海量并发连接数，耗费更少的资源。
二、如何进步Web服务器的并发连贯解决能力
有几个根本条件：
1、基于线程，即一个过程生成多个线程，每个线程响应用户的每个申请。
2、基于事件的模型，一个过程解决多个申请，并且通过epoll机制来告诉用户申请实现。
3、基于磁盘的AIO（异步I/O）
4、反对mmap内存映射，mmap传统的web服务器，进行页面输出时，都是将磁盘的页面先输出到内核缓存中，再由内核缓存中复制一份到web服务器上，mmap机制就是让内核缓存与磁盘进行映射，web服务器，间接复制页面内容即可。不须要先把磁盘的上的页面先输出到内核缓存去。
刚好，Nginx 反对以上所有个性。所以Nginx官网上说，Nginx反对50000并发，是有根据的。
三、Nginx优异之处
传统上基于过程或线程模型架构的Web服务通过每过程或每线程解决并发连贯申请，这势必会在网络和I/O操作时产生阻塞，其另一个必然结果则是对内存或CPU的利用率低下。
生成一个新的过程/线程须要当时备好其运行时环境，这包含为其调配堆内存和栈内存，以及为其创立新的执行上下文等。这些操作都须要占用CPU，而且过多的过程/线程还会带来线程抖动或频繁的上下文切换，零碎性能也会由此进一步降落。
另一种高性能web服务器/Web服务器反向代理：Nginx，Nginx的次要着眼点就是其高性能以及对物理计算资源的高密度利用，因而其采纳了不同的架构模型。受启发于多种操作系统设计中基于“事件”的高级解决机制，Nginx采纳了模块化、事件驱动、异步、单线程及非阻塞的架构，并大量采纳了多路复用及事件告诉机制。
在Nginx中，连贯申请由为数不多的几个仅蕴含一个线程的过程Worker以高效的回环(run-loop)机制进行解决，而每个Worker能够并行处理数千个的并发连贯及申请。
四、Nginx 工作原理
Nginx会按需同时运行多个过程：一个主过程(master)和几个工作过程(worker)，配置了缓存时还会有缓存加载器过程(cache loader)和缓存管理器过程(cache manager)等。所有过程均是仅含有一个线程，并次要通过“共享内存”的机制实现过程间通信。主过程以root用户身份运行，而worker、cache loader和cache manager均应以非特权用户身份运行。
在高连贯并发的状况下，Nginx是Apache服务器不错的替代品。
Nginx 装置十分的简略 , 配置文件十分简洁（还可能反对perl语法）,Bugs 非常少的服务器: Nginx 启动特地容易, 并且简直能够做到7*24不间断运行，即便运行数个月也不须要重新启动. 你还可能 不间断服务的状况下进行软件版本的降级 。
五、Nginx 的诞生次要解决C10K问题
最初咱们从各自应用的多路复用IO模型来剖析：
1、select模型：（apache应用，因为受模块等限度，用的不多）；
单个过程可能 监督的文件描述符的数量存在最大限度；
select()所保护的 存储大量文件描述符的数据结构 ，随着文件描述符数量的增长，其在用户态和内核的地址空间的复制所引发的开销也会线性增长；
因为网络响应工夫的提早使得大量TCP连贯处于非沉闷状态，但调用select()还是会对 所有的socket进行一次线性扫描 ，会造成肯定的开销；
2、poll：poll是unix沿用select本人从新实现了一遍，惟一解决的问题是poll 没有最大文件描述符数量的限度；
3、epoll模型：（Nginx应用）
epoll带来了两个劣势，大幅度晋升了性能：
1）基于事件的就绪告诉形式 ，select/poll形式，过程只有在调用肯定的办法后，内核才会对所有监督的文件描述符进行扫描，而epoll事件通过epoll_ctl()注册一个文件描述符，一旦某个文件描述符就绪时，内核会采纳相似call back的回调机制，迅速激活这个文件描述符，epoll_wait()便会失去告诉
2）调用一次epoll_wait()取得就绪文件描述符时，返回的并不是理论的描述符，而是一个代表就绪描述符数量的值，拿到这些值去epoll指定的一个数组中顺次获得相应数量的文件描述符即可，这里应用内存映射（mmap）技术， 防止了复制大量文件描述符带来的开销
3）当然epoll也有肯定的局限性， epoll只有Linux2.6才有实现 ，而其余平台都没有，这和apache这种优良的跨平台服务器，显然是有些南辕北辙了。
4）简略来说epoll是select的升级版，单过程治理的文件描述符没有最大限度。但epoll只有linux平台可应用。作为跨平台的Apache没有应用
起源：http://codebay.cn/post/8557.html
近期热文举荐：
1.600+ 道 Java面试题及答案整顿(2021最新版)
2.终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！
发表回复