Heim > Artikel > Backend-Entwicklung > apache与php工作原理分析
为大家介绍apache和php的工作原理。 假设有1000个人同一时刻请求php站点,这些请求传给apache服务器,这个时候apache服务器是怎么来工作的? 1.创建1000个进程来处理1000个请求? 2.创建很多个进程,这些进程又包含很多线程来处理1000个请求? 3.其他? 还有fast-cgi,和cgi及php-fpm区别。用上述例子来阐述。 延伸阅读:
大家可以通过以上几篇文章了解下fastcgi与php-fpm的基础知识。 下面我们来看一些概念: 1、CGI和FastCGI是apache处理php脚本的其中两种工作模式,还有ISAPI,SAPI等 2、而php-fpm并不是一种工作模式,而是一个PHP在FastCGI模式运行下的进程管理器,全称为 PHP: FastCGI Process Manager 3、怎么工作的是看你搭建环境的时候使用哪一种工作模式来处理php脚本,当然,少不了的还有你的apache配置(连接数,进程数,线程数等),还有就是所使用的操作系统(不同操作系统对于进程和线程的支持不同,处理能力也不同)。 首先说系统层面吧,不同系统默认会使用不同的多处理模块(MPM),如下:
可以使用apachectl -l 命令来查看当前系统使用哪一种MPM配置。 主要的区别是不同系统使用不同的配置,对于配置项的支持程度也不同。 一般包含以下这些配置项: # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connecti # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: ctant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves 等等。 然后就是apache层面的东西了, 看上面的说明,什么最大连接数啊,每个进程有多少个线程啊,每个进程处理多少个请求什么的,都是可以配置的。怎么处理其中一部分取决于你的配置的值。 然后就是php运行模式的层面了, 现在主流的运行模式是FastCGI,当然有很多以前的配置好的服务器会使用其他模式,具体用命令看一下或者看apache的配置文件就知道了。下面直接贴一段我以前mark下来的内容吧: 1、CGI(通用网关接口/Common Gateway Interface)一般是可执行程序,例如EXE文件,和WEB服务器各自占据着不同的进程,而且一般一个CGI程序只能处理一个用户请求。这样,当用 户请求数量非常多时,会大量占用系统的资源,如内存、CPU时间等,造成效能低下。 2、ISAPI(Internet Server Application Program Interface)是微软提供的一套面向WEB服务的API接口,它能实现CGI提供的全部功能,并在此基础上进行了扩展,如提供了过滤器应用程序接 口。ISAPI应用大多数以DLL动态库的形式使用,可以在被用户请求后执行,在处理完一个用户请求后不会马上消失,而是继续驻留在内存中等待处理别的 用户输入。此外,ISAPI的DLL应用程序和WEB服务器处于同一个进程中,效率要显著高于CGI。 3、FastCGI是可伸缩架构的CGI开放扩展,其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。传统的CGI解释器的反复加载是 CGI性能低下的主要原因,如果CGI解释器保持在内存中并接受FastCGI进程管理器调度,则可以提供良好的性能、伸缩性等。 以 ISAPI 模式运行 PHP 的,这种方式最大的缺点就是稳定性不好,当 PHP 出错的时候,Apache进程也死掉。 FastCGI 模式运行 PHP 的优点: 首先就是 PHP 出错的时候不会搞垮 Apache,只是 PHP 自己的进程当掉(但 FastCGI 会立即重新启动一个新 PHP 进程来代替当掉的进程)。 其次 FastCGI 模式运行 PHP 比 ISAPI 模式性能更好 最后,就是可以同时运行 PHP5 和 PHP4 综合系统层面,apache配置层面,PHP工作模式层面来说,1000个请求是绝对不用1000个进程的,很可能只需要两位数甚至更少的进程就能处理掉了。 |