phpfpm工作原理

A. 服务器程序源代码分析之二：php-fpm

php作为排名top2 互联网开发工具，非常流行，可以参考：中国最大的25个网站采用技术选型方案

php这个名称实际上有两层含义

直接定义：

php-fpm从php5.3.3开始已经进入到php源代码包，之前是作为patch存在的

很少人会去读php本身源代码，我6年前解决php内存泄露问题的时候做了些研究,最近再查看了一番，发现php的开发者很有诚意，这是一款非常出色的服务器软件，支持如下

在linux服务器上，如果不设置 events.mechanism ,那么默认就是采用epoll，所以

php-fpm的IO模型&并发处理能力和nginx是完全一致

nginx以性能卓越闻名，大部分程序员都认为php效率低下，看了源代码，才知道这是传奇啊

在高性能部署的时候，大家往往会针对性的优化nginx 。我自己之前部署php程序也犯了错误，8G内存的server，php-fpm的max children都会设置128+，现在看来太多了，参考nginx的部署:

php-fpm配置为 3倍 cpu core number就可以了

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部署工具，我再也不黑它了

B. 如何通俗的解释cgi，fastcgi，php-fpm之间的关系

这个问题可以分两个层面讨论：

1. PHP 解释器是否嵌入 Web 服务器进程内部执行

mod_php 通过嵌入 PHP 解释器到 Apache 进程中，只能与 Apache 配合使用，而 cgi 和 fast-cgi 以独立的进程的形式出现，只要对应的Web服务器实现 cgi 或者 fast-cgi 协议，就能够处理 PHP 请求。

mod_php 这种嵌入的方式最大的弊端就是内存占用大，不论是否用到 PHP 解释器都会将其加载到内存中，典型的就是处理CSS、JS之类的静态文件是完全没有必要加载解释器。

2. 单个进程处理的请求数量

mod_php 和 fast-cgi 的模式在每个进程的生命周期内能够处理多个请求，而 cgi 的模式处理一个请求就马上销毁进程，在高并发的场景下 cgi 的性能非常糟糕。

综上，如果对性能有极高的要求，可以将静态请求和动态请求分开，这时 Nginx + php-fpm 是比较好的选择。

PS: cgi、fastcgi 通常指 Web 服务器与解释器通信的协议规范，而 php-fpm 是 fastcgi 协议的一个实现。

C. php-fpm怎么连接的mysql

们都知道，php是不能直接操作 mysql的，他需要通过扩展提供接口调用，php的mysql扩展也好几个，只支持面向过程的mysql，既支持面向过程也支持面向对象的mysqli，只支持面向对象的PDO，当然无论是那个扩展，也只是php语法写法上的区别而已，底层其实是一样的。
今天我们不讲语法这些老掉牙的东西，我们随便找一个扩展，来分析一下 php底层 和 mysql 之间的通信原理。
首先我们来理解一下 php-fpm 的工作原理，php-fpm 是一个 php-cgi 进程管理器，其实就是一个连接池，它和nginx配合的工作原理如下。
我们先从最简单的静态方式入手观察他的工作原理
vim php-fpm.ini
[www]
pm = static
pm.max_children = 5
pm.max_requests = 2
上面三句话的含义是什么呢:
1、static 表示静态以静态方式生成 php-fpm 进程
2、pm.max_children = 5 表示当 php-fpm 启动时就启动 5 个 php-fpm 子进程 等待处理 nginx 发过来的请求
3、pm.max_requests = 2 表示每个 php-fpm 子进程处理 2 个请求就销毁，当然父进程每次看到有销毁的自然也就会生成新的子进程
我们来简单验证一下这个说法：
首先重启 php-fpm，让它复位一下
接下来写一条简单的语句输出当前进程ID
echo "当前 php-fpm 进程ID：".posix_getpid();
不断刷新浏览器观察输出变化
当前 php-fpm 进程ID：24548
当前 php-fpm 进程ID：24549
当前 php-fpm 进程ID：24550
当前 php-fpm 进程ID：24547
当前 php-fpm 进程ID：24551
当前 php-fpm 进程ID：24548
当前 php-fpm 进程ID：24549
当前 php-fpm 进程ID：24550
当前 php-fpm 进程ID：24547
当前 php-fpm 进程ID：24551
当前 php-fpm 进程ID：24563
当前 php-fpm 进程ID：24564
当前 php-fpm 进程ID：24565
当前 php-fpm 进程ID：24566
当前 php-fpm 进程ID：24567
当前 php-fpm 进程ID：24563
当前 php-fpm 进程ID：24564
当前 php-fpm 进程ID：24565
当前 php-fpm 进程ID：24566
当前 php-fpm 进程ID：24567
当前 php-fpm 进程ID：24568
当前 php-fpm 进程ID：24569
当前 php-fpm 进程ID：24570
当前 php-fpm 进程ID：24571
当前 php-fpm 进程ID：24572
当前 php-fpm 进程ID：24568
当前 php-fpm 进程ID：24569
当前 php-fpm 进程ID：24570
当前 php-fpm 进程ID：24571
当前 php-fpm 进程ID：24572
可以看得出，第一批id不是按照顺序执行的，进程id为24547的进程是在第四位处理的，然后从下面开始，所有id都是顺序执行的而且每次生成的一批id都是递增，是不是有种mysql自增主键的赶脚呢？
这里需要注意的是，无论是静态还是下面的动态配置方式，只要没有设置 max_requests ，那么进程是不会销毁的，也就是说当一个进程里面出现死循环或者内存溢出等导致进程僵死的情况出现的时候，处理的进程就会少一个了
好吧理解了静态的处理方式，我们其实也很容易知道这个方式的弊端了，当然我们平时服务器不可能就开5个进程每个进程处理2个请求，我们来做一个简单的加减乘除，看看一个服务器应该开多少个 php-fpm 合适
首先我们来看看一个简单的echo需要多少内存：
$size = memory_get_usage();
$unit = array('b','kb','mb','gb','tb','pb');
$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];
echo "当前 php-cgi 进程所使用内存：".$memory;
观察浏览器我们可以得到一下数据：
当前 php-cgi 进程所使用内存：227.17 kb
也就是说一个简单的什么都不干的php就已经占用了200多K的内存，当然这也不算多。
不过进程多了cpu切换进程速度就会变慢，所以这个数还是需要通过ab等测试工具才能测试出具体应该开多少比较合理
我们先从200开始，不断的增加，架设增加到800的时候，效率和400一样，那我们就没必要开800那么多进程浪费内存了。
那么问题就来了，如果同一时间请求出超过400呢？有人说会排队等待，真的会排队等待吗？答案明显是 php-fpm 是没能力排队了，因为处理请求的php-fpm子进程都用完了，那么等待也就只能是在 nginx 等待，通常一个 nginx 也不只是转发请求给 php-fpm 就完事了，他还要处理静态文件呢？如果这些php请求导致nginx的请求数过多一直在等待，那么访问静态文件自然也会卡了，这时候我们就需要配置成下面的动态处理方式。
[www]
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
;pm.max_requests = 2
上面五句话的含义是什么呢:
1、dynamic 表示静态以动态方式生成 php-fpm 进程
2、pm.max_children = 10 同时活动的进程数 10个
3、pm.start_servers = 5 表示当 php-fpm 主进程启动时就启动 5 个 php-fpm 子进程
4、pm.min_spare_servers = 2 表示最小备用进程数
5、pm.max_spare_servers = 8 表示最大备用进程数
6、pm.max_requests = 2 上面说过就不说了
当前 php-fpm 进程ID：2270
当前 php-fpm 进程ID：2271
当前 php-fpm 进程ID：2272
当前 php-fpm 进程ID：2273
当前 php-fpm 进程ID：2274
当前 php-fpm 进程ID：2270
当前 php-fpm 进程ID：2271
当前 php-fpm 进程ID：2272
当前 php-fpm 进程ID：2273
当前 php-fpm 进程ID：2274
当前 php-fpm 进程ID：2270
当前 php-fpm 进程ID：2271
当前 php-fpm 进程ID：2272
当前 php-fpm 进程ID：2273
当前 php-fpm 进程ID：2274

D. PHP中的FPM是做什么的

FPM（FastCGI 进程管理器）用于替换 PHP FastCGI 的大部分附加功能，对于高负载网站是非常有用的。它的功能包括：

• 支持平滑停止/启动的高级进程管理功能；

• 可以工作于不同的 uid/gid/chroot 环境下，并监听不同的端口和使用不同的 php.ini 配置文件（可取代 safe_mode 的设置）；

• stdout 和 stderr 日志记录;

• 在发生意外情况的时候能够重新启动并缓存被破坏的 opcode;

• 文件上传优化支持;

• "慢日志" - 记录脚本（不仅记录文件名，还记录 PHP backtrace 信息，可以使用 ptrace或者类似工具读取和分析远程进程的运行数据）运行所导致的异常缓慢;

• fastcgi_finish_request() - 特殊功能：用于在请求完成和刷新数据后，继续在后台执行耗时的工作（录入视频转换、统计处理等）；

• 动态／静态子进程产生；

• 基本 SAPI 运行状态信息（类似Apache的 mod_status）；

• 基于 php.ini 的配置文件。

E. 关于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+代理模式了

F. php5-cgi和php5-fpm 这两个东西是什么意思啊有什么区别

什么是PHP-CGI:
PHP-CGI是PHP自带的FastCGI管理器。
启动PHP-CGI，使用如下命令：
php-cgi -b 127.0.0.1:9000
PHP-CGI的不足:
1、php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效，不可以平滑重启
2、直接杀死php-cgi进程,php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑从新生成新的子进程。）
什么是PHP-FPM
PHP-FPM是一个PHP FastCGI管理器，是只用于PHP的,可以在 http://php-fpm.org/download下载得到.
PHP-FPM其实是PHP源代码的一个补丁，旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中，在编译安装PHP后才可以使用。
现在我们可以在最新的PHP 5.3.2的源码树里下载得到直接整合了PHP-FPM的分支，据说下个版本会融合进PHP的主分支去。相对Spawn-FCGI，PHP-FPM在CPU和内存方面的控制都更胜一筹，而且前者很容易崩溃，必须用crontab进行监控，而PHP-FPM则没有这种烦恼。
PHP5.3.3已经集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP进程管理方式，可以有效控制内存和进程、可以平滑重载PHP配置，比spawn-fcgi具有更多有点，所以被PHP官方收录了。在./configure的时候带 –enable-fpm参数即可开启PHP-FPM。
二者的区别：
php-cgi是被调用的进程，php-fpm是配置和管理进程的。

G. nginx和php-fpm之间是怎样通信的

FastCGI原理
FastCGI是一个运用于Http Server和动态脚本语言间通信的接口，多数流行的Http Server都支持FastCGI，包括Apache、Nginx和lighttpd等。同时，FastCGI也被许多脚本语言支持，其中就有PHP。
FastCGI接口方式采用C/S结构，可以将HttP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HttP服务器每次遇到动态程序时，可以将其直接交付给FastCGI进程来执行，然后将得到的结果返回给客户端。这种方式可以让HttP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提高了整个应用系统的性能。

Nginx+php-fpm实现原理

Nginx本身不会对PHP进行解析，终端对PHP页面的请求将会被Nginx交给FastCGI进程监听的IP地址及端口，由php-fpm作为动态解析服务器处理，最后将处理结果再返回给nginx。其实，Nginx就是一个反向代理服务器。Nginx通过反向代理功能将动态请求转向后端php-fpm，从而实现对PHP的解析支持，这就是Nginx实现PHP动态解析的原理。

Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket（这个socket可以是文件socket，也可以是ip socket）。为了调用CGI程序，还需要一个FastCGI的wrapper（wrapper可以理解为用于启动另一个程序的程序），这个wrapper绑定在某个固定socket上，如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候，通过FastCGI接口，wrapper接收到请求，然后派生出一个新的线程，这个线程调用解释器或者外部程序处理脚本并读取返回数据；接着，wrapper再将返回的数据通过FastCGI接口，沿着固定的socket传递给Nginx；最后，Nginx将返回的数据发送给客户端。

Nginx 简单配置
location ~ \.php$ {
root /home/admin/web/nginx/html/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/admin/web/nginx/html/$fastcgi_script_name;
include fastcgi_params;
}