中国领先的IT技术网站
51CTO旗下网站
为什么我们使用Nginx而不是Apache？
Apache是非常强大的Web服务器，模块化结构，也是Web服务端的鼻祖。世界上大多数网站仍运行着Apache系统。但是，Apache并不是完美的，并且不再适合大规模系统。为什么？因为他的进程模式虽然简单而灵活，但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。
作者：Steve Mushero来源：| 10:14
我们大多数的客户在他们的服务器上使用Apache作为Web服务器，尤其是部署在一个基于PHP系统的前端并且使用mod-PHP。鉴于扩张性和性能方面的原因，我们通常会建议他们改用Nginx和FPM。
Apache是非常强大的Web服务器，模块化结构，也是Web服务端的鼻祖。除了捆绑一些其他的工具外，Apache已经成为了世上最广泛部署的开源系统，直到最近，世界上大多数网站仍运行着Apache系统。
但是，Apache并不是完美的，并且不再适合大规模系统。为什么？因为他的进程模式虽然简单而灵活，但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。
一个典型的网络应用服务器由两部分组成。客户端连接部分负责用户浏览器与HTTP连接，保持长时间的TCP/IP协议，通常是1到2分钟。对于一个大型的系统，服务器可能要同时承担和处理数以万计的并发连接。
这直接与Apache只有500条进程即500个HTTP连接的处理能力上限相冲突。而现今的浏览器让这个问题更加严重, 因为现在的浏览器平均每个主机会打开六个网站链接（几年前是两个网站链接）。所以当超过100个用户同时访问时，Apache就已经满负荷了。
第二部分是应用程序处理部分，这部分承担了代码运算。在大多数系统中，这部分工作是最消耗RAM和CPU资源的，因此进程数量必须被严格限制，通常是大约每 1GB的内存10个进程，或者每个CPU核心两个进程。因此一台4GB RAM、16内核的服务器最多只能运行32个应用程序进程。
但是，问题的关键是，Apache直接连接前端客户端通讯组件与后端应用程序进程组件。如此一来，前端部分往往保持长时间的连接，常常达到几分钟，这导致后端部分将持续消耗内存和CPU资源。目前还没有直接的方法能够在大型系统中找到前后端服务的平衡，因此他们必须被分离开来。
目前有两个主要的解决方法。第一个方法，也是现有系统上最容易的方法，就是在Apache前端安装负载均衡服务器或者Nginx来处理客户端连接部分。负载均衡服务器，像 HAProxy或者Nginx能轻松处理成千上万条并发的连接，并使Apache能够真正的仅作为后端应用程序工作，来处理32个或是更多的进程。
第二种方案，也是最通用的办法就是用Nginx替换Apache，同时使用PHP-PFM作为应用服务器。就像之前所提到的，这将分割前端客户端通信部分和后端应用程序部分。Nginx处理HTTP通讯协议，同时FPM处理后端应用程序部分，和那32个进程进行交互。
然而这几种方法仍然还存在一些问题，主要是如何加载服务器的RPC调用，以及如何释放已经完成的RPC调用。 这两个问题都会在后继的博客中加以详解。
另外，只使用Nginx的解决方法会给那些严重依赖于Apache功能的应用程序带来问题，尤其是特别依赖rewrite rules, .htaccess, 或者mod_security等一些可选组件的应用程序。在这种情况下，在Apache前端增加安装Nginx是最好的方法。
通常来说，所有新的系统都应该使用Nginx和PHP-FPM来部署。这能提供高性能增长特性，并且是平衡用户和内存，CPU资源的最佳选择。已存在的系统可以在前端使用Nginx或者HAProxy以达到同样的效果，以便在当今现代网络环境中为用户提供更优质的服务。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条外电头条外电
24H热文一周话题本月最赞
讲师：0人学习过
讲师：0人学习过
讲师：11人学习过
精选博文论坛热帖下载排行
本书是数据库系统方面的经典教材之一。国际上许多著名大学包括斯坦福大学、耶鲁大学、得克萨斯大学、康奈尔大学、伊利诺伊大学、印度理工学...
订阅51CTO邮刊当前位置：&>&&>&
Apache和Nginx运行原理解析
发布时间：
来源：服务器之家
Web服务器也称为WWW(WORLD WIDE WEB)服务器，主要功能是提供网上信息浏览服务。
应用层使用HTTP协议。
HTML文档格式。
浏览器统一资源定位器(URL)。
Web服务器常常以B/S（Browser/Server）方式提供服务。浏览器和服务器的交互方式如下：
&GET&/index.php&HTTP/1.1
&+---------------+&&&&&&&&&&&&&&&&&&&+----------------+
&|&&&&&&&&&&&&&&&+-------------------&&&&&&&&&&&&&&&&&|
&|&&&Browser&&&&&|&&&&&&&&&&&&&&&&&&&|&&&Server&&&&&&&|
&|&&&&&&&&&&&&&&&&-------------------+&&&&&&&&&&&&&&&&|
&+---------------+&&&&&&&&&&&&&&&&&&&+----------------+
&&&&&&&&&&&&&&&&&&&HTTP/1.1&200&OK
浏览器向服务器发出HTTP请求(Request)。
服务器收到浏览器的请求数据，经过分析处理，向浏览器输出响应数据（Response）。
浏览器收到服务器的响应数据，经过分析处理，将最终结果显示在浏览器中。
Apache和Nginx都属于Web服务器，两者都实现了HTTP 1.1协议。
Apache 概述
Apache HTTP
Server是Apache软件基金会的一个开放源代码的网页服务器，可以在大多数计算机操作系统中运行，由于其跨平台和安全性。被广泛使用，是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充，将Perl／Python等解释器编译到服务器中。
-- 维基百科
Apache组件
Apache是基于模块化设计的，它的核心代码并不多，大多数的功能都被分散到各个模块中，各个模块在系统启动的时候按需载入。
"text"&&&&&&&&&&+----------+
&&&&&&+-&|&Module&&&|&-----------------+
&&&&&&|&&+----------+&&&&&&&&&&&&&&&&&&|
&&&&&&|&&&&&&&&&&&&&&&&&&&&&&&&&&+------------+
+-----------+&&&Apache&HTTPD&&&&&|&php&module&|
|&Module&&&&|&&&&&&&&&&&&&&&&&&&&+------------+
+-----------+&&&&&&&&&&&&&&+----------+|
&&&&&&+----------+--------&|&&MPM&&&&&|+
&&&&&&&&&&&&&&&&&|&&&&&&&&&+----+---+-+
&&&&&&&&&&&&&&&+-v-----------+&&|&&&|
&&&&&&&&&&&&&&&|&&&&ARP&&&&&&&--+&&&|
&&&&&&&&&&&&&&&+------+------+&&&&&&|
&&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&|
&&&&&&+---------------v-------------v--+
&&&&&&|&&&&&&Operating&&System&&&&&&&&&|
&&&&&&+--------------------------------+
MPM（Multi -Processing
Modules，多重处理模块）是Apache的核心组件之一，Apache通过MPM来使用操作系统的资源，对进程和线程池进行管理。Apache为了能够获得最好的运行性能，针对不同的平台
(Unix/Linux、Window)做了优化，为不同的平台提供了不同的MPM，用户可以根据实际情况进行选择，其中最常使用的MPM有
prefork和worker两种。至于您的服务器正以哪种方式运行，取决于安装Apache过程中指定的MPM编译参数,在X系统上默认的编译参数为
由于大多数的Unix都不支持真正的线程，所以采用了预派生子进程(prefork)方式，象Windows或者Solaris这些支持
线程的平台，基于多进程多线程混合的worker模式是一种不错的选择。Apache中还有一个重要的组件就是APR（Apache
portable Runtime
Library），即Apache可移植运行库，它是一个对操作系统调用的抽象库，用来实现Apache内部组件对操作系统的使用，提高系统的可移植性。
Apache对于php的解析，就是通过众多Module中的php Module来完成的。
Apache生命周期
"text"&&&&+--------------------------------------------------------------+
&&&|&&&&&&&&&&&&&&&&&+---------------------+&&&&&&&启动阶段&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&|&&&&系统启动,&配置&&&&&|&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&+----------+----------+&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&+----------v----------+&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&|&&&&&&模块的初始化&&&&&|&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&+-+--------+--------+-+&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&&&&&&&&&&&&&&&&&|&&&&&&&&|&&&&&&&&|&&&&&&&&&&&&&&&&&&&&&&&&|
&&&|&&&+-------------+&|&+------v-------+|&+--------------+&&&&&&&|
&&&|&&&|&子进程初始化&&|&+&|&子进程初始化&&&|+&|&&子进程初始化&&|&&&&&&&|
&&&|&&&+------+------+&&&+-------+------+&&+-------+------+&&&&&&&|
&&&+--------------------------------------------------------------+
&&&|&&&&&&&&&&|&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&|&&&&&运行阶段&&|
&&&|&&&&&+----v----+&&&&&&&&+----v----+&&&&&&&+----v----+&&&&&&&&&|
&&&|&&&&&|&请求循环&|&&&&&&&&|&&请求循环&|&&&&&&&|&请求循环&|&&&&&&&&&|
&&&|&&&&&+----+----+&&&&&&&&+----+----+&&&&&&&+----+----+&&&&&&&&&|
&&&|&&&&&&&&&&|&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&|
&&&|&&&+------v------+&&&&+------v------+&&&+------v------+&&&&&&&|
&&&|&&&|&&子进程结束&&&|&&&&|&&子进程结束&&|&&&|&&&子进程结束&&|&&&&&&&|
&&&|&&&+-------------+&&&&+-------------+&&&+-------------+&&&&&&&|
&&&+--------------------------------------------------------------+
这个生命周期是在perfork工作下的示意，从图中可以看出，Apache对于每一个请求都要启动一个单独的进程来处理。
Apache的工作模式 prefork的工作原理
一个单独的控制进程(父进程)负责产生子进程，这些子进程用于监听请求并作出应答。Apache总是试图保持一些备用的
(spare)或是空闲的子进程用于迎接即将到来的请求。这样客户端就无需在得到服务前等候子进程的产生。在Unix系统中，父进程通常以root身份运行以便邦定80端口，而
Apache产生的子进程通常以一个低特权的用户运行。User和Group指令用于配置子进程的低特权用户。运行子进程的用户必须要对他所服务的内容有读取的权限，但是对服务内容之外的其他资源必须拥有尽可能少的权限。
worker的工作原理
每个进程能够拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程能够建立ThreadsPerChild数量的服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。Apache总是试图维持一个备用(spare)或是空闲的服务线程池。这样，客户端无须等待新线程或新进程的建立即可得到处理。在Unix中，为了能够绑定80端口，父进程一般都是以root身份启动，随后，Apache以较低权限的用户建立子进程和线程。User和Group指令用于配置Apache子进程的权限。虽然子进程必须对其提供的内容拥有读权限，但应该尽可能给予他较少的特权。另外，除非使用了suexec
，否则，这些指令配置的权限将被CGI脚本所继承。
Apache的运行 启动阶段
在启动阶段，Apache主要进行配置文件解析(例如http.conf以及Include指令设定的配置文件等)、模块加载(例如modphp.so,modperl.so等)和系统资源初始化（例如日志文件、共享内存段等）工作。在这个阶段，Apache为了获得系统资源最大的使用权限，将以特权用户root（X系统）或超级管理员administrator(Windows系统)完成启动。
这个过程可以通过下图来深入了解：
"text"&&&&&&&&+--------+
&&&&&&&|&&开始&&&|
&&&&&&&+----+---+
&&&&&&&&&&&&|
&+----------v------------+&&&解析主配置文件http.conf中配置信息，
&|&&&&&解析配置文件&&&&&&&&|&&&像LoadModule,&AddType
&+----------+------------+&&&等指令被加载至内存
&&&&&&&&&&&&|
&+----------v------------+&&&依据AddModule,&LoadModule等指令
&|&&&加载静态/动态模块&&&&&&|&&&加载Apache模块，像mod_php5.so被
&+----------+------------+&&&加载至内存，映射到Apache地址空间。
&&&&&&&&&&&&|
&+----------v------------+&&&日志文件、共享内存段，数据库链接
&|&&&&&系统资源初始化&&&&&&|&&&&等初始化
&+----------+------------+
&&&&&&&&&&&&|
&&&&&&&&+---v----+
&&&&&&&&|&&结束&&&|
&&&&&&&&+--------+
在运行阶段，Apache主要工作是处理用户的服务请求。在这个阶段，Apache放弃特权用户级别，使用普通权限，这主要是基于安全性的考虑，防止由于代码的缺陷引起的安全漏洞。
由于Apache的Hook机制，Apache
允许模块(包括内部模块和外部模块，例如mod_php5.so,mod_perl.so等)将自定义的函数注入到请求处理循环中。mod_php5.so/php5apache2.dll就是将所包含的自定义函数，通过Hook机制注入到Apache中，在Apache处理流程的各个阶段负责处理php请求。
Apache将请求处理循环分为11个阶段，依次是：Post-Read-Request，URI
Translation，Header Parsing，Access
Control，Authentication，Authorization，MIME Type
Checking，FixUp，Response，Logging，CleanUp。
Apache处理http请求的生命周期:
Post-Read-Request阶段:在正常请求处理流程中，这是模块可以插入钩子的第一个阶段。对于那些想很早进入处理请求的模块来说，这个阶段可以被利用。
URI Translation阶段 :
Apache在本阶段的主要工作：将请求的URL映射到本地文件系统。模块可以在这阶段插入钩子，执行自己的映射逻辑。mod_alias就是利用这个阶段工作的。
Header Parsing阶段 :
Apache在本阶段的主要工作：检查请求的头部。由于模块可以在请求处理流程的任何一个点上执行检查请求头部的任务，因此这个钩子很少被使用。mod_setenvif就是利用这个阶段工作的。
Access Control阶段 :
Apache在本阶段的主要工作：根据配置文件检查是否允许访问请求的资源。Apache的标准逻辑实现了允许和拒绝指令。modauthzhost就是利用这个阶段工作的。
Authentication阶段 :
Apache在本阶段的主要工作：按照配置文件设定的策略对用户进行认证，并设定用户名区域。模块可以在这阶段插入钩子，实现一个认证方法。
Authorization阶段 :
Apache在本阶段的主要工作：根据配置文件检查是否允许认证过的用户执行请求的操作。模块可以在这阶段插入钩子，实现一个用户权限管理的方法。
MIME Type Checking阶段 :
Apache在本阶段的主要工作：根据请求资源的MIME类型的相关规则，判定将要使用的内容处理函数。标准模块modnegotiation和modmime实现了这个钩子。
FixUp阶段 :
这是一个通用的阶段，允许模块在内容生成器之前，运行任何必要的处理流程。和PostReadRequest类似，这是一个能够捕获任何信息的钩子，也是最常使用的钩子。
Response阶段 :
Apache在本阶段的主要工作：生成返回客户端的内容，负责给客户端发送一个恰当的回复。这个阶段是整个处理流程的核心部分。
Logging阶段 :
Apache在本阶段的主要工作：在回复已经发送给客户端之后记录事务。模块可能修改或者替换Apache的标准日志记录。
CleanUp阶段 :
Apache在本阶段的主要工作：清理本次请求事务处理完成之后遗留的环境，比如文件、目录的处理或者Socket的关闭等等，这是Apache一次请求处理的最后一个阶段。
Nginx 概述
Nginx（发音同engine x）是一款由俄罗斯程序员Igor
Sysoev所开发轻量级的网页服务器、反向代理服务器以及电子邮件（IMAP/POP3）代理服务器。起初是供俄国大型的门户网站及搜索引擎Rambler（俄语：Рамблер）使用。
-- 维基百科
Nginx的模块与工作原理
Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件将客户端请求映射到一个location
block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
Nginx的模块从结构上分为核心模块、基础模块和第三方模块：
核心模块：HTTP模块、EVENT模块和MAIL模块
基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP
Rewrite模块，
第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access
Nginx的模块从功能上分为如下三类:
Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）。此类模块是Nginx的HTTP
Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。
"text"&&&&&&&&&&&&&&&&&&&&&&+&&&&&&&&&&&&&&&&&&&&^
&&&&&&&&Http&Request&|&&&&&&&&&&&&&&&&&&&&|&&Http&Response
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&&&|
&&&&+---------+------v-----+&&&&&&&&&+----+----+
&&&&|&&Conf&&&|&Nginx&Core&|&&&&&&&&&|&FilterN&|
&&&&+---------+------+-----+&&&&&&&&&+----^----+
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&&&|
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&+----+----+
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&|&Filter2&|
choose&a&handler&&&&&|&&&&&&&&&&&&&&&+----^----+
based&conf&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&&&|
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&+----+----+
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&|&Filter1&|
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&+----^----+
&&&&&&&&&&&&&&&&&&&&&|&&&&&&&&&&&&&&&&&&&&|&Generate&content
&&&&&&&&&&&&&&&+-----v--------------------+----+
&&&&&&&&&&&&&&&|&&&&&&&&&&&Handler&&&&&&&&&&&&&|
&&&&&&&&&&&&&&&+-------------------------------+
Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location
block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。
Nginx架构及工作流程
上图是Nginx的架构，这个架构类似于Apache的Worker工作状态，Nginx的每一个Worker进程都管理着大量的线程，真正处理请求的是Worker之下的线程。
所有实际上的业务处理逻辑都在worker进程。worker进程中有一个函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个nginx服务被停止。Worker中这个函数执行内容如下：
操作系统提供的机制（例如epoll, kqueue等）产生相关的事件。
接收和处理这些事件，如是接受到数据，则产生更高层的request对象。
处理request的header和body。
产生响应，并发送回客户端。
完成request的处理。
重新初始化定时器及其他事件。
Nginx和FastCGI FastCGI
FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP
server都支持FastCGI，包括Apache、Nginx和lighttpd等。同时，FastCGI也被许多脚本语言支持，其中就有PHP。
FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差，因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析，然后将结果返回给HTTP服务器。这在处理高并发访问时几乎是不可用的。另外传统的CGI接口方式安全性也很差，现在已经很少使用了。
FastCGI接口方式采用C/S结构，可以将HTTP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时，可以将其直接交付给FastCGI进程来执行，然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提高了整个应用系统的性能。
Nging和FastCGI合作
Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket（这个socket可以是文件socket，也可以是ip
socket）。
接下来以Nginx下PHP的运行过程来说明。PHP-FPM是管理FastCGI的一个管理器，它作为PHP的插件存在。
FastCGI进程管理器php-fpm自身初始化，启动主进程php-fpm和启动start_servers个CGI
子进程。主进程php-fpm主要是管理fastcgi子进程，监听9000端口。fastcgi子进程等待来自Web
Server的连接。
当客户端请求到达Web Server
Nginx是时，Nginx通过location指令，将所有以php为后缀的文件都交给127.0.0.1:9000来处理，即Nginx通过location指令，将所有以php为后缀的文件都交给127.0.0.1:9000来处理。
FastCGI进程管理器PHP-FPM选择并连接到一个子进程CGI解释器。Web
server将CGI环境变量和标准输入发送到FastCGI子进程。
FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web
Server。当FastCGI子进程关闭连接时，请求便告处理完成。
FastCGI子进程接着等待并处理来自FastCGI进程管理器（运行在 WebServer中）的下一个连接。
Apache和Nginx比较 功能对比
Nginx和Apache一样，都是HTTP服务器软件，在功能实现上都采用模块化结构设计，都支持通用的语言接口，如PHP、Perl、Python等，同时还支持正向和反向代理、虚拟主机、URL重写、压缩传输、SSL加密传输等。
在功能实现上，Apache的所有模块都支持动、静态编译，而Nginx模块都是静态编译的，
对FastCGI的支持，Apache对Fcgi的支持不好，而Nginx对Fcgi的支持非常好；
在处理连接方式上，Nginx支持epoll，而Apache却不支持；
在空间使用上，Nginx安装包仅仅只有几百K，和Nginx比起来Apache绝对是庞然大物。
Nginx相对apache的优点
轻量级，同样起web 服务，比apache 占用更少的内存及资源
静态处理，Nginx 静态处理性能比 Apache 高 3倍以上
抗并发，nginx 处理请求是异步非阻塞的，而apache则是阻塞型的，在高并发下nginx
能保持低资源低消耗高性能。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。
高度模块化的设计，编写模块相对简单
社区活跃，各种高性能模块出品迅速啊
apache相对nginx的优点
rewrite，比nginx 的rewrite 强大
模块超多，基本想到的都可以找到
少bug，nginx的bug相对较多
Apache对PHP支持比较简单，Nginx需要配合其他后端用
选择Nginx的优势所在
作为Web服务器: Nginx处理静态文件、索引文件，自动索引的效率非常高。
作为代理服务器，Nginx可以实现无缓存的反向代理加速，提高网站运行速度。
作为负载均衡服务器，Nginx既可以在内部直接支持Rails和PHP，也可以支持HTTP代理服务器对外进行服务，同时还支持简单的容错和利用算法进行负载均衡。
在性能方面，Nginx是专门为性能优化而开发的，在实现上非常注重效率。它采用内核Poll模型(epoll and kqueue
)，可以支持更多的并发连接，最大可以支持对50 000个并发连接数的响应，而且只占用很低的内存资源。
在稳定性方面，Nginx采取了分阶段资源分配技术，使得CPU与内存的占用率非常低。Nginx官方表示，Nginx保持10
000个没有活动的连接，而这些连接只占用2.5MB内存，因此，类似DOS这样的攻击对Nginx来说基本上是没有任何作用的。
在高可用性方面，Nginx支持热部署，启动速度特别迅速，因此可以在不间断服务的情况下，对软件版本或者配置进行升级，即使运行数月也无需重新启动，几乎可以做到7×24小时不间断地运行。
同时使用Nginx和Apache
由于Nginx和Apache各自的优势，现在很多人选择了让两者在服务器中共存。在服务器端让Nginx在前，Apache在后。由Nginx做负载均衡和反向代理，并且处理静态文件，讲动态请求（如PHP应用）交给Apache去处理。
Copyright © . 版权所有老男孩oldboy 的BLOG
用户名：老男孩oldboy
文章数：556
评论数：7015
访问量：4824432
注册日期：
阅读量：5863
阅读量：12276
阅读量：419457
阅读量：1107778
51CTO推荐博文
部分内容摘自跟老男孩学Linux运维:Web集群实战（运维人员必备书籍） && 1.select 和epoll模型区别1.1.网络IO模型概述&&&&&通常来说，网络IO可以抽象成用户态和内核态之间的数据交换。一次网络数据读取操作（read），可以拆分成两个步骤：1）网卡驱动等待数据准备好（内核态）2）将数据从内核空间拷贝到进程空间（用户态）。根据这两个步骤处理方式不一样，我们通常把网络IO划分成阻塞IO和非阻塞IO。& & & ?阻塞IO。用户调用网络IO相关的系统调用时（例如read），如果此时内核网卡还没有读取到网络数据，那么本次系统调用将会一直阻塞，直到对端系统发送的数据到达为止。如果对端一直没有发送数据，则本次调用将永远不会返回。& & & ?非阻塞IO。当用户调用网络IO相关的系统调用时（例如read），如果此时内核网络还没有收到网络数据，那么本次系统调用将会立即返回，并返回一个EAGAIN的错误码。在没有IO多路复用技术之前，由于没有一种好的方式来探测网络IO是否可读可写。因此，为了增加系统的并发连接量，一般是借助多线程或多进程的方式来增加系统的并发连接数。但是这种方式有个问题就是系统的并发连接数受限于操作系统的最大线程或进程数，并且随着操作系统的线程或进程数增加，将会引发大量的上下文切换，导致系统的性能急剧下降。为了解决这个问题，操作系统引入了IO多路转接技术（IO multiplexing）。1.2.IO多路转接技术&&&&IO多路转接技术其实就是使用select、epoll等操作系统提供的系统调用来检测IO事件的各种机制。通过select、epoll等机制，我们可以很轻松的同时管理大量的网络IO连接，并且获取到处于活跃状态的连接。当其中一个或多个发生网络IO事件时，select、epoll等系统调用就会返回相应的连接，我们就可以对这些连接进行读取或写入操作，从而完成网络数据交互。1.3.select 工作原理& & & &select函数原型：&&&&&&&&int select(int nfds, fd_set *readfds, fd_set *writefds,fd_set *exceptfds, struct timeval *timeout);&&&&&&&&&&select各个参数说明：& & & & & & & &?nfds这个参数的值一般设置为读集合（readfds）、写集合（writefds）以及exceptfds（异常集合）中最大的描述符（fd）+1，当然也可以设置为FD_SETSIZE。FD_SETSIZE是操作系统定义的一个宏，一般是1024。也就是说读写以及异常集合大小的最大值是1024，所以使用select最多只能管理1024个连接。如果大于1024个连接，select将会产生不确定行为。?readfds指向可读描述符集的指针，如果我们关心连接的可读事件，需要把连接的描述符设置到读集合中。?writefds指向可写描述符集的指针，如果我们关心连接的可写事件，需要把连接的描述符设置到可写集合中。?exceptfds指向异常描述符集的指针，如果我们关心连接的是否发生异常，需要把连接的描述符设置到异常描述符集合中。?timeout指select愿意等待的时间。&&&&&&&&&&&&& &&&&&&& struct timeval {&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& longtv_&&&&& //秒数&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& longtv_&&& //微秒数&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& }&&&&&&&&&&&&&&&&一般来说，分为三种情况：?timeout为空，select将会永远等待。直到有连接可读、可写或者被信号中断时返回。?timeout-&tv_sec = 0 且 timeout-&tv_usec = 0，完全不等待。检测所有指定的描述符后立即返回。这是得到多个描述符的状态而不阻塞select函数的轮询方法。?timeout-&tv_sec != 且 timeout-&tv_usec != 0，等待指定的秒数和微秒数。当指定的描述符之一已经准备好，或者超过了指定的时间值，则立即返回。如果超时了，还没有一个描述符准备好，则返回0。& & &select的工作原理，select通过轮询来检测各个集合中的描述符（fd）的状态，如果描述符的状态发生改变，则会在该集合中设置相应的标记位；如果指定描述符的状态没有发生改变，则将该描述符从对应集合中移除。因此，select的调用复杂度是线性的，即O(n)。举个例子，一个保姆照看一群孩子，如果把孩子是否需要尿尿比作网络IO事件，select的作用就好比这个保姆挨个询问每个孩子：你要尿尿吗？如果孩子回答是，保姆则把孩子拎出来放到另外一个地方。当所有孩子询问完之后，保姆领着这些要尿尿的孩子去上厕所（处理网络IO事件）。& & select的限制，前面提到FD_SETSIZE宏，这个宏是操作系统定义的。在linux下面通常是1024，也就是说select最多只能管理1024个描述符。如果大于1024的个描述，select将会产生不可预知的行为。那在没有poll或epoll的情况下，怎样使用select来处理连接数大于1024的情况呢？答案是使用多线程技术，每个线程单独使用一个select进行检测。这样的话，你的系统能够处理的并发连接数等于线程数*1024。早期的apache就是这种技术来支撑海量连接的。1.4.epoll工作原理& epoll函数原型：& & & & int epoll_create(int size);&&&&&&& intepoll_ctl(int epfd, int op, int fd, struct epoll_event *event);& & & & & & & & &&int epoll_wait(intepfd, &struct epoll_event *events, intmaxevents, &int timeout);&&&&&&&&&epoll依赖上述三个函数，既可以完成成千上万的并发连接管理。epoll使用方式，1）通过epoll_create建立epoll句柄。2）将描述符所感兴趣的事件通过epoll_ctl添加到epoll句柄中。3）调用epoll_wait返回所有可读写的描述符。& epoll是为处理大批量而作了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量中只有少量活跃的情况下的系统CPU利用率。另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高效率。&&&&&&还是以保姆照看一群孩子为例，在epoll机制下，保姆不再需要挨个的询问每个孩子是否需要尿尿。取而代之的是，每个孩子如果自己需要尿尿的时候，自己主动的站到事先约定好的地方，而保姆的职责就是查看事先约定好的地方是否有孩子。如果有小孩，则领着孩子去上厕所（网络事件处理）。因此，epoll的这种机制，能够高效的处理成千上万的并发连接，而且性能不会随着连接数增加而下降。1.5.select和epoll对比综上所述，select和epoll对比如下表所示selectepoll性能随着连接数增加，急剧下降。处理成千上万并发连接数时，性能很差。随着连接数增加，性能基本上没有下降。处理成千上万并发连接时，性能很好。连接数连接数有限制，处理的最大连接数不超过1024。如果要处理超过1024个连接数，则需要修改FD_SETSIZE宏，并重新编译 。连接数无限制。内在处理机制线性轮询回调callback开发复杂性低中&老男孩教育最新课程select和epoll简单区别比喻select的调用复杂度是线性的，即O(n)。举个例子，一个保姆照看一群孩子，如果把孩子是否需要尿尿比作网络IO事件，select的作用就好比这个保姆挨个询问每个孩子：你要尿尿吗？如果孩子回答是，保姆则把孩子拎出来放到另外一个地方。当所有孩子询问完之后，保姆领着这些要尿尿的孩子去上厕所（处理网络IO事件）。还是以保姆照看一群孩子为例，在epoll机制下，保姆不再需要挨个的询问每个孩子是否需要尿尿。取而代之的是，每个孩子如果自己需要尿尿的时候，自己主动的站到事先约定好的地方，而保姆的职责就是查看事先约定好的地方是否有孩子。如果有小孩，则领着孩子去上厕所（网络事件处理）。因此，epoll的这种机制，能够高效的处理成千上万的并发连接，而且性能不会随着连接数增加而下降。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
18:48:17 18:41:14 23:46:08