在高并发连接的情形下，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内存（15M10=150M），开启的64个php-cgi进程花费1280M内存（20M64=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做事器的并发连接处理能力有几个基本条件：
基于线程，即一个进程天生多个线程，每个线程响运用户的每个要求。
基于事宜的模型，一个进程处理多个要求，并且通过epoll机制来关照用户要求完成。
基于磁盘的AIO（异步I/O）
支持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 启动特殊随意马虎, 并且险些可以做到724不间断运行，纵然运行数个月也不须要重新启动. 你还能够 不间断做事的情形下进行软件版本的升级 。
五、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作为一个跨平台的Web做事器，须要支持多种操作系统，因此选择了其他的事宜驱动模型来实现高并发处理。
