导读:今天编程笔记来给各位分享关于php-fpm干什么的的相关内容,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
1、php5-cgi和php5-fpm 这两个东西是什么意思啊?有什么区别?怎么使用
2、关于FastCGI、php-cgi、php-fpm的区别是什么,各自有什么用途,以及相互间的关系是什么?
3、php中fastcgi和php-fpm是什么东西
4、了解PHP-FPM
5、php-fpm的工作机制
php5-cgi和php5-fpm 这两个东西是什么意思啊?有什么区别?怎么使用
CGI
CGI全称是“公共网关接口”(Common Gateway Interface),HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具,其程序须运行在网络服务器上。
CGI可以用任何一种语言编写,只要这种语言具有标准输入、输出和环境变量。如php,perl,tcl等。
FastCGI
FastCGI像是一个常驻(long-live)型的CGI,它可以一直执行着,只要激活后,不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。它还支持分布式的运算,即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。
FastCGI是语言无关的、可伸缩架构的CGI开放扩展,其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知,CGI解释器的反复加载是CGI性能低下的主要原因,如果CGI解释器保持在内存中并接受FastCGI进程管理器调度,则可以提供良好的性能、伸缩性、Fail- Over特性等等。
FastCGI特点
FastCGI具有语言无关性.
FastCGI在进程中的应用程序,独立于核心web服务器运行,提供了一个比API更安全的环境。APIs把应用程序的代码与核心的web服务器链接在一起,这意味着在一个错误的API的应用程序可能会损坏其他应用程序或核心服务器。 恶意的API的应用程序代码甚至可以窃取另一个应用程序或核心服务器的密钥。
FastCGI技术目前支持语言有:C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相关模块在Apache, ISS, Lighttpd等流行的服务器上也是可用的。
FastCGI的不依赖于任何Web服务器的内部架构,因此即使服务器技术的变化, FastCGI依然稳定不变。
FastCGI的工作原理
Web Server启动时载入FastCGI进程管理器(IIS ISAPI或Apache Module)
FastCGI进程管理器自身初始化,启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
当客户端请求到达Web Server时,FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时,请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中,php-cgi在此便退出了。
在上述情况中,你可以想象CGI通常有多慢。每一个Web请求PHP都必须重新解析php.ini、重新载入全部扩展并重初始化全部数据结构。使用FastCGI,所有这些都只在进程启动时发生一次。一个额外的好处是,持续数据库连接(Persistent database connection)可以工作。
FastCGI的不足
因为是多进程,所以比CGI多线程消耗更多的服务器内存,PHP-CGI解释器每进程消耗7至25兆内存,将这个数字乘以50或100就是很大的内存数。
Nginx 0.8.46+PHP 5.2.14(FastCGI)服务器在3万并发连接下,开启的10个Nginx进程消耗150M内存(15M*10=150M),开启的64个php-cgi进程消耗1280M内存(20M*64=1280M),加上系统自身消耗的内存,总共消耗不到2GB内存。如果服务器内存较小,完全可以只开启25个php-cgi进程,这样php-cgi消耗的总内存数才500M。
上面的数据摘自Nginx 0.8.x + PHP 5.2.13(FastCGI)搭建胜过Apache十倍的Web服务器(第6版)
PHP-CGI
PHP-CGI是PHP自带的FastCGI管理器。
PHP-CGI的不足:
php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效,不可以平滑重启。
直接杀死php-cgi进程,php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑从新生成新的子进程。)
PHP-FPM
PHP-FPM是一个PHP FastCGI管理器,是只用于PHP的,可以在 下载得到。
PHP-FPM其实是PHP源代码的一个补丁,旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中,在编译安装PHP后才可以使用。
关于FastCGI、php-cgi、php-fpm的区别是什么,各自有什么用途,以及相互间的关系是什么?
fastcgi是一个通用网关接口,用于web服务器(iis, apache)和应用程序通信。
php-cgi是php平台的cgi程序
以上两个结合,可以使php整合在web服务中
php-fpm是一个独立的php-fcgi管理软件,它要整合进web服务中,需要使用代理模式
一般与nginx搭配。也可以与apache搭配
php-fpm一般不直接作为服务容器提供外网访问,而是通过常用web容器作代理
php作为服务器端的解析程序,运行模式分很多种,fastcgi, mod_php, proxy(代理)等。
与iis搭配时一般采用fast-cgi模式,iis自带fast-cgi引擎,配置好php参数即可
与apache搭配,在windows平台下,一般也是fast-cgi模式,在linux系统中一般是mod_php模式,把php作为一个子模块加载
也可以配置php-fpm 然后在apache中配置代理模式
与nginx搭配,一般就是用php-fpm+代理模式了
php中fastcgi和php-fpm是什么东西
Fastcgi是CGI的升级版,一种语言无关的协议,用来沟通程序(如PHP, Python, Java)和Web服务器(Apache2, Nginx), 理论上任何语言编写的程序都可以通过Fastcgi来提供Web服务。
Fastcgi的特点是会在一个进程中依次完成多个请求,以达到提高效率的目的,大多数Fastcgi实现都会维护一个进程池。
而PHP-fpm就是针对于PHP的,Fastcgi的一种实现,他负责管理一个进程池,来处理来自Web服务器的请求。目前,PHP-fpm是内置于PHP的。
了解PHP-FPM
在服务器上,当我们查看php进程时,全都是php-fpm进程,大家都知道这个就是php的运行环境,那么,它到底是个什么东西呢?
PHP-FPM,就是PHP的FastCGI管理器,用于替换PHP FastCGI的大部分附加功能,在PHP5.3.3后已经成为了PHP的标配。
有小伙伴要问了,FastCGI又是什么鬼?CGI程序又叫做“通用网关接口”,就是让Web服务器和你的应用程序进行交互的一个接口。就像nginx中需要配置的fastcgi_pass,一般我们会使用127.0.0.1:9000或者unix:/tmp/php-cgi.sock来配置这个参数。它的意思就是告诉nginx,过来的请求使用tcp:9000端口的监听程序来处理或者使用unix/socket来处理。它们都是指向的PHP运行程序。
再说得通俗一点,我们运行php脚本用的是
php-fpm就相当于是这个php命令。nginx通过fastcgi_pass来运行php $nginx_root(nginx配置文件中网站根目录root配置)下的index.php。所以,如果你用的是python或者其他什么语言,都可以用它们的cgi程序来让nginx调用。
FastCGI和CGI又有什么不同呢?FastCGI是启动一个socket接口,服务器应用不需要自己去运行php,只需要向这个socket接口提交请求就可以了。
php-fpm在编译php时需要添加--enable-fpm。一些通用的集成安装包如lnmp、phpStudy等都会默认编译并使用php-fpm,毕竟是标配。
上文中说过nginx可以使用127.0.0.1:9000和unix:/tmp/php-cgi.sock这两种方式来调用php-fpm。它们有什么区别呢?
前者,一般带9000端口号的,是tcp形式的调用。也就是php-fpm启动了一个监听进程对9000端口进行监听。它会调起一个tcp/ip服务,nginx在调用的时候会走一次tcp请求流程,也就是3次握手4次挥手,会走到网络七层中的第四层传输层。相对来说这种方式性能会稍差一点,启动php-fpm后使用nestat查看端口中会出现9000端口的占用。
后者,使用的是unix套接字socket服务,通过sock文件来交换信息,性能相对好一些,因为它没有tcp连接过程,也不会有9000端口的占用。
对于高负载大访问量的网站还是推荐使用unix方式,对于普通小网站来说,无所谓使用哪个都可以,tcp方式反而更容易配置和理解,也是php-fpm.conf中默认的监听方式。
php-fpm.conf配置中的listen属性用来配置监听,这里的配置要和nginx中的一致,使用tcp的就监听127.0.0.1:9000,使用unix的就设置成/tmp/php-cgi-56.sock。
以下内容摘自官方文档:
===========
各自媒体平台均可搜索【硬核项目经理】
php-fpm的工作机制
概括来说,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中。
(2)fpm_scoreboard_init_main():
分配用于记录 worker 进程运行信息的共享内存,按照 worker pool 的最大 worker 进程数分配,每个 worker pool 分配一个fpm_scoreboard_s结构,pool 下对应的每个 worker 进程分配一个fpm_scoreboard_proc_s结构。
(3)fpm_signals_init_main():
这里会通过socketpair()创建一个管道,这个管道并不是用于 master 与 worker 进程通信的,它只在 master 进程中使用,具体用途在稍后介绍 event 事件处理时再作说明。另外设置 master 的信号处理 handler,当 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 这些信号时将调用sig_handler()处理:
(4)fpm_sockets_init_main()
创建每个 worker pool 的 socket 套接字。
(5)fpm_event_init_main():
启动 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 进程一次请求的处理被划分为 5 个阶段:
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() 函数中,这里不再罗列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
这是进程管理实现的主要事件,master 启动了一个定时器,每隔 1s 触发一次,主要用于 dynamic、ondemand 模式下的 worker 管理,master 会定时检查各 worker pool 的 worker 进程数,通过此定时器实现 worker 数量的控制,处理逻辑如下:
(3)fpm_pctl_heartbeat():
这个事件是用于限制 worker 处理单个请求最大耗时的,php-fpm.conf 中有一个request_terminate_timeout的配置项,如果 worker 处理一个请求的总时长超过了这个值那么 master 将会向此 worker 进程发送kill -TERM信号杀掉 worker 进程,此配置单位为秒,默认值为 0 表示关闭此机制,另外 fpm 打印的 slow log 也是在这里完成的。
除了上面这几个事件外还有一个没有提到,那就是 ondemand 模式下 master 监听的新请求到达的事件,因为 ondemand 模式下 fpm 启动时是不会预创建 worker 的,有请求时才会生成子进程,所以请求到达时需要通知 master 进程,这个事件是在fpm_children_create_initial()时注册的,事件处理函数为fpm_pctl_on_socket_accept(),具体逻辑这里不再展开,比较容易理解。
原文出处:
结语:以上就是编程笔记为大家介绍的关于php-fpm干什么的的全部内容了,希望对大家有所帮助,如果你还想了解更多这方面的信息,记得收藏关注本站。