Nginx、Apache工作原理以及nginx为何比Apache高效
短短几年，Nginx拿下了不少web服务器。众所周知，Nginx在处理大并发静态请求时，效率明显高于httpd，甚至可以轻松解决C10K问题。
在高并发连接的情况下，Nginx是Apacheserver的一个很好的替代方案。Nginx也可以用作7层负载均衡服务器。根据我的测试结果，Nginx0.7.14+PHP5.2.6(FastCGI)可以承载超过30000个并发连接，是同等环境下Apache的10倍。
一般来说，一个4GB内存+Apache(prefork模式)的服务器只能处理3000个并发连接，因为它们会占用3GB以上的内存，还得为系统预留1GB的内存。我曾经有两台Apache服务器，因为配置文件中设置的MaxClients是4000。当Apache并发连接数达到3800时，服务器内存和Swap空耗尽并崩溃。
在这个Nginx0.7.14+PHP5.2.6(FastCGI)服务器中，30000个并发连接下，10个Nginx进程启动消耗150M内存(15M*10=150M)，64个php-cgi进程启动消耗1280M内存(20M*64=1280M)，加上系统本身消耗的内存。如果服务器内存较小，只能启动25个php-cgi进程，这样php-cgi消耗的总内存只有500M。
在3万并发连接下，访问Nginx0.7.14+PHP5.2.6(FastCGI)服务器的PHP程序还是很快的。
为什么Nginx在处理高并发上优于httpd？先说两个web服务器的工作原理和模式。
阿帕奇的三种工作模式
我们都知道Apache有三个工作模块，分别是prefork、worker和event。
Prefork:多进程，每个请求由一个进程响应，这个进程会被select机制通知。
Worker:多线程，一个进程可以生成多个线程，每个线程响应一个请求，但是通知机制还是select，但是可以接受更多的请求。
事件:基于异步I/O模型，基于事件驱动(即epoll机制)实现一个进程或线程，每个进程或线程响应多个用户请求。
4.2Prefork的工作原理
如果不显式指定带“-with-mpm”的mpm，Prefork是Unix平台上默认的MPM，其预派生的子进程模式也是Apache1.3中采用的模式，Prefork本身不使用线程，2.0版本使用它来保持与1.3版本的兼容性；另一方面，prefork使用单独的子进程来处理不同的请求，并且这些进程相互独立，这使得它成为最稳定的MPM之一。
4.3工人的工作原理
与prefork相比，worker是2.0版本新增的MPM，支持多线程多进程混合模式。因为使用线程进行处理，所以可以处理相对大量的请求，并且系统资源的开销小于基于进程的服务器。然而，worker也使用多个进程，并且每个进程生成多个线程，从而获得基于进程的服务器的稳定性。这种MPM将是Apache2.0的发展趋势
4.4基于事件机制的事件特征
一个进程响应多个用户的请求，并使用回调机制来重用套接字。请求来了之后，进程不处理请求，直接交给其他机制，通过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(EngineX)。nginx的主要着眼点是物理计算资源的高性能和高密度利用，因此采用了不同的架构模型。受各种 *** 作系统设计中基于“事件”的高级处理机制的启发，nginx采用模块化、事件驱动、异步、单线程、非阻塞架构，大量采用了复用和事件通知机制。在nginx中，连接请求由几个只有一个线程的流程工作者在高效的运行循环机制中处理，每个工作者可以并行处理数千个并发连接和请求。
nginx的工作原理
Nginx将根据需要同时运行多个进程:一个主进程和几个worker。配置缓存时，将有一个缓存加载器进程和一个缓存管理器进程。所有进程只有一个线程，进程间通信主要通过“共享内存”的机制来实现。主进程作为根用户运行，而工作进程、缓存加载器和缓存管理器都应该作为非特权用户运行。
在高连接并发的情况下，Nginx是Apacheserver的一个很好的替代品。
NGX的安装非常简单，配置文件非常简洁(也可以支持perl语法)，bug非常少的服务器:Nginx非常容易启动，即使运行几个月也几乎可以7*24运行，不需要任何重启。您还可以升级软件版本，而不会中断服务。
Nginx的诞生主要解决了C10K的问题。
最后我们从相互使用的复用IO模型来分析:
选择模型:(apache是使用的，但是由于模块等的限制使用的不多。)
单个进程可以监视的文件描述符的数量有一个最大限制。
select()维护的数据结构存储了大量的文件描述符。随着文件描述符数量的增加，用户状态和内核地址空之间的复制带来的开销也会线性增加。
由于网络响应时间的延迟，大量的TCP连接处于非活动状态，但是调用select()还是会线性扫描所有socket，会造成一定的开销。
poll:轮询由unix使用select本身重新实现。唯一需要解决的问题是Poll没有文件描述符的最大数量。
Epoll型号:(由nginx使用)
Epoll带来了两大优势，极大地提高了性能:
基于事件就绪通知方法select/poll方法，内核只有在进程调用某个方法后才会扫描所有被监控的文件描述符，epoll事件通过epoll_ctl()注册一个文件描述符。一旦一个文件描述符准备好了，内核就会采用类似回调的回调机制，快速激活文件描述符，epoll_wait()就会得到通知。
当调用一次epoll_wait()来获取就绪文件描述符时，返回的描述符不是实际的描述符，而是表示就绪描述符数量的值。只需获取这些值，并在epoll指定的数组中获取相应数量的文件描述符。这里使用内存映射(mmap)技术来避免复制大量文件描述符带来的开销。
当然，epoll也有一定的局限性。epoll只在Linux2.6中实现，其他平台都没有，这显然与apache这种优秀的跨平台服务器背道而驰。
简单来说，epoll是select的升级版，对单进程管理的文件描述符没有最大限制。但是epoll只能在linux平台上使用。不使用Apache作为跨平台。
微信扫一扫
支付宝扫一扫
评论列表（0条）