您好,我来为您解答：
PHP-FPM是一个PHP FastCGI管理器,是只用于PHP的.
PHP-FPM其实是PHP源代码的一个补丁,旨在将FastCGI进程管理整合进PHP包中.必须将它patch到你的PHP源代码中,在编译安装PHP后才可以使用.
新版PHP已经集成php-fpm了,不再是第三方的包了,推荐使用.PHP-FPM提供了更好的PHP进程管理方式,可以有效控制内存和进程、可以平滑重载PHP配置,比spawn-fcgi具有更多优点,所以被PHP官方收录了.在./configure的时候带 –enable-fpm参数即可开启PHP-FPM,其它参数都是配置php的,转载,仅供参考.
如果我的回答没能帮助您,请继续追问.
概括来说,fpm 的实现就是创建一个 master 进程,在 master 进程中创建并监听 socket,然后 fork 出多个子进程,这些子进程各自 accept 请求,子进程的处理非常简单,它在启动后阻塞在 accept 上,有请求到达后开始读取请求数据,读取完成后开始处理然后再返回,在这期间是不会接收其它请求的,也就是说 fpm 的子进程同时只能响应一个请求,只有把这个请求处理完成后才会 accept 下一个请求,这一点与 nginx 的事件驱动有很大的区别,nginx 的子进程通过 epoll 管理套接字,如果一个请求数据还未发送完成则会处理下一个请求,即一个进程会同时连接多个请求,它是非阻塞的模型,只处理活跃的套接字.
fpm 的 master 进程与 worker 进程之间不会直接进行通信,master 通过共享内存获取 worker 进程的信息,比如 worker 进程当前状态、已处理请求数等,当 master 进程要杀掉一个 worker 进程时则通过发送信号的方式通知 worker 进程.
fpm 可以同时监听多个端口,每个端口对应一个 worker pool,而每个 pool 下对应多个 worker 进程,类似 nginx 中 server 概念.
在 php-fpm.conf 中通过[pool name]声明一个 worker pool：
启动 fpm 后查看进程：
具体实现上 worker pool 通过fpm_worker_pool_s这个结构表示,多个 worker pool 组成一个单链表
此时此刻呢看下 fpm 的启动流程,从main()函数开始：
fpm_init()主要有以下几个关键操作：
(1) fpm_conf_init_main():
解析 php-fpm.conf 配置文件,分配 worker pool 内存结构并保存到全局变量中：fpm_worker_all_pools,各 worker pool 配置解析到fpm_worker_pool_s-config中.
分配用于记录 worker 进程运行信息的共享内存,按照 worker pool 的最大 worker 进程数分配,每个 worker pool 分配一个fpm_scoreboard_s结构,pool 下对应的每个 worker 进程分配一个fpm_scoreboard_proc_s结构.
创建每个 worker pool 的 socket 套接字.
启动 master 的事件管理,fpm 实现了一个事件管理器用于管理 IO、定时事件,其中 IO 事件通过 kqueue、epoll、poll、select 等管理,定时事件就是定时器,一定时间后触发某个事件.
在fpm_init()初始化完成后此时此刻呢就是最关键的fpm_run()操作了,此环节将 fork 子进程,启动进程管理器,另外 master 进程将不会再返回,只有各 worker 进程会返回,也就是说fpm_run()之后的操作均是 worker 进程的.
在 fork 后 worker 进程返回了监听的套接字继续 main() 后面的处理,而 master 将永远阻塞在fpm_event_loop(),此时此刻呢分别介绍 master、worker 进程的后续操作.
fpm_run()执行后将 fork 出 worker 进程,worker 进程返回main()中继续向下执行,后面的流程就是 worker 进程不断 accept 请求,然后执行 PHP 脚本并返回.整体流程如下：
worker 处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s-request_stage,master 进程正是通过这个标识判断 worker 进程是否空闲的.
此时此刻呢我们来看下 master 是如何管理 worker 进程的,首先介绍下三种不同的进程管理方式：
前面介绍到在fpm_run()中 master 进程将进入fpm_event_loop()：
这就是 master 整体的处理,其进程管理主要依赖注册的几个事件,此时此刻呢我们详细分析下这几个事件的功能.
(1)sp[1]管道可读事件：
在 fpm_init() 阶段 master 曾创建了一个全双工的管道：sp,然后今天这一节创建了一个 sp[0] 可读的事件,当 sp[0] 可读时将交由 fpm_got_signal() 处理,向 sp[1] 写数据时 sp[0] 才会可读,那么什么时机会向 sp[1] 写数据呢?前面已经提到了：当 master 收到注册的那几种信号时会写入 sp[1] 端,这个时候将触发 sp[0] 可读事件.
这个事件是 master 用于处理信号的,我们根据 master 注册的信号逐个看下不同用途：
具体处理逻辑在 fpm_got_signal() 函数中,这里不再罗列.
这是进程管理实现的主要事件,master 启动了一个定时器,每隔 1s 触发一次,主要用于 dynamic、ondemand 模式下的 worker 管理,master 会定时检查各 worker pool 的 worker 进程数,通过此定时器实现 worker 数量的控制,处理逻辑如下：
这个事件是用于限制 worker 处理单个请求最大耗时的,php-fpm.conf 中有一个request_terminate_timeout的配置项,如果 worker 处理一个请求的总时长超过了这个值那么 master 将会向此 worker 进程发送kill -TERM信号杀掉 worker 进程,此配置单位为秒,默认值为 0 表示关闭此机制,另外 fpm 打印的 slow log 也是今天这一节完成的.
原文出处：
php这个名称实际上有两层含义
直接定义：
在linux服务器上,如果不设置 events.mechanism ,那么默认就是采用epoll,所以
php-fpm的IO模型并发处理能力和nginx是完全一致
nginx以性能卓越闻名,大部分程序员都认为php效率低下,看了源代码,才知道这是传奇啊
php-fpm稳定性比nginx稍差 这是因为php-fpm内置了一个php解析器,php-fpm进程就和php程序捆绑了,如果php脚本写得不好,有死循环或者阻塞在某个远端资源上,会拖累加载它的php-fpm进程
而nginx和后端应用服务器之间通过网络连接,可以设置timeout,不容易堵死的
php-fpm的fastcgi是短连接 我原以为是长连接的,看了代码才知道也是短连接,处理一个request就关闭掉
php-fpm接口采用fastcgi 非常遗憾,php-fpm和fastcgi完全绑定了,无法独立使用 .只能部署在支持http-fcgi协议转换程序背后(nginx）.其实可以考虑在php-fpm代码包里面引入http协议支持,这样php-fpm可以独立运行,让nodejs无话可说
php-fpm等同于OpenResty OpenResty是一个国人开发的nginx模块,就是在nginx引入lua解释器. 实际上,它和php-fpm的唯一差别就是一个采用php语法,一个用lua,所以OpenResty要作为nginx增强包使用还可以,要选择它作为一个主要编程工具,没有任何必要
从架构上来说,php-fpm已经做到最好,超过大多数 python部署工具,我再也不黑它了
首先,CGI是干嘛的?CGI是为了保证web server传递过来的数据是标准格式的,方便CGI程序的编写者
web server（比如说nginx）只是内容的分发者.比如,如果请求/index.html,那么web server会去文件系统中找到这个文件,发送给浏览器,这里分发的是静态数据.好了,如果现在请求的是/index.php,根据配置文件,nginx知道这个不是静态文件,需要去找PHP解析器来处理,那么他会把这个请求简单处理后交给PHP解析器.Nginx会传哪些数据给PHP解析器呢?url要有吧,查询字符串也得有吧,POST数据也要有,HTTP header不能少吧,好的,CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议.仔细想想,你在PHP代码中使用的用户从哪里来的.
当web server收到/index.php这个请求后,会启动对应的CGI程序,这里就是PHP的解析器.此时此刻呢PHP解析器会解析php.ini文件,初始化执行环境,然后处理请求,再以规定CGI规定的格式返回处理后的结果,退出进程.web server再把结果返回给浏览器.
好了,CGI是个协议,跟进程什么的没关系.那fastcgi又是什么呢?Fastcgi是用来提高CGI程序性能的.
提高性能,那么CGI程序的性能问题在哪呢?"PHP解析器会解析php.ini文件,初始化执行环境",就是这里了.标准的CGI对每个请求都会执行这些步骤（不闲累啊！启动进程很累的说！）,所以处理每个时间的时间会比较长.这明显不合理嘛！那么Fastcgi是怎么做的呢?首先,Fastcgi会先启一个master,解析配置文件,初始化执行环境,然后再启动多个worker.当请求过来时,master会传递给一个worker,然后立即可以接受下一个请求.这样就避免了重复的劳动,效率自然是高.而且当worker不够用时,master可以根据配置预先启动几个worker等着；当然空闲worker太多时,也会停掉一些,这样就提高了性能,也节约了资源.这就是fastcgi的对进程的管理.
那PHP-FPM又是什么呢?是一个实现了Fastcgi的程序,被PHP官方收了.
大家都知道,PHP的解释器是php-cgi.php-cgi只是个CGI程序,他自己本身只能解析请求,返回结果,不会进程管理（皇上,臣妾真的做不到啊！）所以就出现了一些能够调度php-cgi进程的程序,比如说由lighthttpd分离出来的spawn-fcgi.好了PHP-FPM也是这么个东东,在长时间的发展后,逐渐得到了大家的认可（要知道,前几年大家可是抱怨PHP-FPM稳定性太差的）,也越来越流行.
网上有的说,fastcgi是一个协议,php-fpm实现了这个协议有的说,php-fpm是fastcgi进程的管理器,用来管理fastcgi进程的,对.php-fpm的管理对象是php-cgi.但不能说php-fpm是fastcgi进程的管理器,因为前面说了fastcgi是个协议,似乎没有这么个进程存在,就算存在php-fpm也管理不了他（至少目前是）. 有的说,php-fpm是php内核的一个补丁
以前是对的.因为最开始的时候php-fpm没有包含在PHP内核里面,要使用这个功能,需要找到与源码版本相同的php-fpm对内核打补丁,然后再编译.后来PHP内核集成了PHP-FPM之后就方便多了,使用--enalbe-fpm这个编译参数即可.
有的说,修改了php.ini配置文件后,没办法平滑重启,所以就诞生了php-fpm,是的,修改php.ini之后,php-cgi进程的确是没办法平滑重启的.php-fpm对此的处理机制是新的worker用新的配置,已经存在的worker处理完手上的活就可以歇着了,通过这种机制来平滑过度.
还有的说PHP-CGI是PHP自带的FastCGI管理器,那这样的话干吗又弄个php-fpm出
不对.php-cgi只是解释PHP脚本的程序而已.
第一步：确定php-fpm配置文件的路径,执行：
ps -aux | grep php-fpm
user = www
group = www
以上就是土嘎嘎小编为大家整理的包含fpm依赖php的词条相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！