b.通过CGI来实现,这个就好比之前perl的CGI,该种方式的缺点是性能差,因为每次服务器遇到这些脚本都需要重新启动脚本解析器来执行脚本然后将结果返回给服务器;另一方面就是不太安全;该方面几乎很少使用了。
c.最新出现一种叫做FastCGI。所谓FastCGI就是对CGI的改进。它一般采用C/S结构,一般脚本处理器会启动一个或者多个daemon进 程,每次HTTPServer遇到脚本的时候,直接交付给FastCGI的进程来执行,然后将得到的结果(通常为html)返回给浏览器。
>该种方法的问题存在一个小问题是当遇到大流量的频繁请求的话,脚本处理器的daemon进程可能会超负荷从而变得很慢,甚至发生内存泄漏;
>但是比较起Apache的内置模块的方式的优点是由于Server和脚本解析器完全分开各负其责,因此服务器不再臃肿,可以专心地进行静态文件响 应或者将动态脚本解析器的结果返回给用户客户端。所以比较起Apache的内置模块方式,有时候性能要提高很多。有人测试可能会达到 Apache+mod_php的5~10倍。
b. 该两者还可以分出一个好坏来,spawn-fcgi由于是lighttpd的一部分,因此安装了lighttpd一般就会使用spawn-fcgi对 php支持,但是目前有用户说ligttpd的spwan-fcgi在高并发访问的时候,会出现上面说的内存泄漏甚至自动重启fastcgi。即:PHP 脚本处理器当机,这个时候如果用户访问的话,可能就会出现白页(即PHP不能被解析或者出错)。
另一个:首先nginx不像lighttpd本身含带了fastcgi(spawn-fcgi),因此它完全是轻量级的,必须借助第三方的FastCGI 处理器才可以对PHP进行解析,因此其实这样看来nginx是非常灵活的,它可以和任何第三方提供解析的处理器实现连接从而实现对PHP的解析(在 nginx.conf中很容易设置)。
nginx可以使用spwan-fcgi(需要一同安装lighttpd,但是需要为nginx避开端口,一些较早的blog有这方面安装的教程),但是 由于spawn-fcgi具有上面所述的用户逐渐发现的缺陷,现在慢慢减少使用nginx+spawn-fcgi组合了。
c. 由于spawn-fcgi的缺陷,现在出现了新的第三方(目前还是,听说正在努力不久将来加入到PHP core中)的PHP的FastCGI处理器,叫做PHP-FPM(具体可以google)。它和spawn-fcgi比较起来有如下优点:
由于它是作为PHP的patch补丁来开发的,安装的时候需要和php源码一起编译,也就是说编译到php core中了,因此在性能方面要优秀一些;
同时它在处理高并发方面也优于spawn-fcgi,至少不会自动重启fastcgi处理器。具体采用的算法和设计可以google了解。
因此,如上所说由于nginx的轻量和灵活性,因此目前性能优越,越来越多人逐渐使用这个组合:
三者后两者性能可能稍优,但是Apache由于有丰富的模块和功能,目前来说仍旧是老大。有人测试nginx+PHP-FPM在高并发情况下可能会达到Apache+mod_php5的5~10倍,现在nginx+PHP-FPM使用的人越来越多。
模块加载进来,从而实现Apache对php的支持。
1)由于该模式实在太经典了,因此这里关于安装部分不准备详述了,相对来说比较简单。
2)这里之所以仍旧列出来Apache+mod_php5来讨论,是因为:
因此,建议nginx(1个或者多个)+多个apache的架构继续使用下去。
1)通过上面的分析,尽管我们可以仍旧保留Apache+mod_php来处理PHP,所有的静态文件和负载均衡由顶在前端的nginx来完成,但是由于nginx和PHP-FPM各自的优越性,使得nginx+PHP-FPM的组合的性能已经很超越Apache+mod_php。
因此现在出现了新的名词叫做
其中看不到Apache的影子了,全部由nginx来搞定。nginx轻量型,高性能,高灵活性使得它完全能够应付过来。
由于PHP-FPM是C/S结构,因此我们前端保留nginx来做负载均衡;对于之前后端的各个Apache服务器,我们不需要安装Apache了,对PHP重新编译安装使其以PHP-FPM方式支持FastCGI;
然后在nginx中配置将客户端的php请求分别pass到后台的多个运行的PHP-FPM,后者进行处理然后返回给nginx,然后显示给用户。整个过程可以完全不要Apache。
3) 下面我们具体来介绍如何来安装和简单配置
这里之所以首先要安装MySQL,是因为之后编译安装PHP的时候,可以直接指定对MySQL的支持。
我们知道PHP对MySQL的支持是通过PHP扩展实现的。
可以源代码安装,不过我使用的Ubuntu,直接使用了其发布的二进制包安装了:
安装的时候需要提示设置root密码;
我们之前介绍了PHP-FPM是对PHP的补丁,因此需要和PHP一起编译安装。我这里使用的
注意两个版本尽量相同(不相同可能出错,我自己没试过)。
倘若中间需要哪个命令shell不认识,可以使用apt-get安装,或者google找答案。
在安装之前可能需要安装几个依赖包:
不安装也可以,之后./configure失败的话,根据出错信息,再慢慢搜索安装依赖包也可以,重要的是记下关键步骤,因为每个人的系统装没装啥都不一定。
这里我们配置php安装到/usr/local/php,如果不配置默认安装到/usr/local下,这样我觉得不太好,这样make install各个文件就会被拷贝得分散开来(分散在local的各个目录下),如果我们之后想卸载干净而且无法使用make uninstall的话,还不方便。安装到/usr/local/php下,如果我们想删除php,直接删除该目录即可。
注意:这里需要注意的一个问题是,不要设置--with-apxs2=/usr/local/apache2/bin/apxs,我们知道它是告诉PHP编译成模块方式让Apache来支持。如果设置了该选项的话,编译安装之后,Apache会无法启动,报错信息:
因此这里也就意味着,我们编译PHP以PHP-FPM的方式来支持FastCGI的话,基本上就不能和Apache一起使用了,也就是说我们决定使用nginx+PHP+PHP-FPM的话,这里的PHP就没法和Apache一起使用了。
另外,如果该步骤出现错误,通常是缺乏依赖包,请按照错误信息安装依赖包即可。
注意这里尽量使用make all,而不要仅仅是make
将php.ini文件拷贝到如上位置;
这里一般没有严格需要配置什么,可以按照自己要求进行配置。
该文件是一个xml文件,只需要修改:
c. 配置完之后,就可以启动PHP-FPM:
我们上面介绍了FastCGI模式区别于CGI模式,它需要一个daemon进程一直运行在后台对php请求做出解析,这里的PHP-FPM就是这个 daemon进程,在配置文件php-fpm.conf中可以设置它侦听的IP和端口,默认为127.0.0.1:9000。也就是它侦听9000端口的 数据请求,然后会将其进行解析然后返回给请求端。
解了Server的负担,Server有更多资源来处理并发请求。其实这也是nginx优于apache的一个原因。
之前文章我们介绍了nginx的安装和使用nginx作为reverser server的进行负载均衡配置了,感兴趣的可以参看。
我们之前的文章介绍了nginx的使用非常灵活,有人比喻其为server领域的瑞士军刀,其实确实是:性能好,而且使用方法多。
各种使用方法都是通过配置文件来实现,因此
掌握nginx的使用,除了掌握各种架构的思想之外,还要掌握如何对nginx.conf进行相应的配置。
我们这里着重对nginx.conf配置,实现通过php-fpm的fastcgi对php的处理。其实nginx本身并不会对PHP进行解析,这个要区别于Apache (Apache通过内置模块实现了对PHP的解析),nginx其实是将对php页面的请求交给了后台在 侦听的php-fpm,后者具有解析php的功能。
因此如果把php-fpm看做一个app server的话,其实nginx这里的作用还是一个反向代理服务器。和我们之前介绍的使用location配置将php请求proxypass给后台侦听的Apache服务器,在思想上几乎一样。
从上往下对默认的配置文件进行修改:
配置fastcgi参数文件,具体可以参考
基本上可以使用默认的该文件,不需要修改。
如果以上步骤出现错误,通常都是因为nginx.conf配置不正确,可以google寻找解决方法,一般都可以找得到(英文)。然后重新修改nginx.conf文件。
之后需要重启nginx,可以执行:
和nginx对多台app server代理实现负载均衡类似,我们可以实现nginx对多台php-fpm实现负载均衡:
我们可以使用到生产环境中的:
可以使用以上任一种,不过有各种测试表明
nginx处理静态文件,及对php并发请求对后台多台app server的负载均衡;
nginx处理静态文件及将php并发请求发送到后台php-fpm来解析;
另外:关于如何更好使用nginx这个轻量级高性能的瑞士军刀,主要是如何配置nginx.conf,更多参看:
另外,关于PHP支持的各种缓存等这里没有安装,感兴趣可以另行安装。
有可能以后会将PHP-FPM直接添加到PHP内核中一起进行发布