对php-fpm的理解重述

目录

CGI的出现

　　早期的Web服务器只能处理HTML等静态文件，随着PHP等动态语言的出现，Web Server无法进行处理。为解决Web Server处理PHP的问题，Web Server可以将其转交给PHP解释器进行处理。那么，问题就转变为：如何解决Web Server同PHP解释器的通信？
　　于是，CGI协议便出现了。它解决 不同语言解释器（如PHP解释器）与WebServer的通信问题。CGI是Web Server与后台语言交互的协议，具有语言无关性。开发者可以按照CGI协议的要求使用任何语言编写程序，就能实现语言解释器同Web Server的通信。如php-cgi程序。
　　尽管如此，但是我们发现，CGI中存在着一个致命的问题：为处理每次请求均需要fork出一个全新的CGI进程，请求处理完成后又将进程kill掉。具体过程如下：
　　当Web Server接收到请求，如请求PHP时，发现自身处理不了，会启动对应的CGI程序。接下来PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，再以CGI规定的格式返回处理后的结果，最后退出进程。Web Server收到结果后将其返回给浏览器。
　　每次请求都需要fork出一个进程出来，然后让PHP解析器解析php.ini文件，初始化执行环境，处理请求，最后将进程kill掉。显然，从高并发、资源占用、效率的角度来说，这种方式是不太合理的。

FastCGI

　　于是，FastCGI出现了。顾名思义，这是CGI的一个改进，“更快的”CGI。在FastCGI中，请求处理完毕后，不会立即kill掉处理请求的进程，而是保留该进程，等待处理下一次请求。它允许在一个进程内处理多个请求。并不是一个请求fork出一个进程，这在性能上得到了很大的提高。

php-fpm

　　php-fpm便是FastCGI协议的具体实现，提供了进程管理的功能。在php-fpm中，采用了master/worker架构设计，分为master进程和worker进程。其中master进程只有一个，负责CGI、PHP公共环境的初始化、监听端口，接收来自 Web Server 的请求；而worker进程则一般有多个（具体数据根据实际需要配置），每个进程内部都嵌入了一个 PHP 解释器，是 PHP 代码真正执行的地方。在worker进程处理请求时，无需再次初始化PHP运行环境，这也是php-fpm性能优异的原因之一。

摘录

来源： 深入理解PHP之：Nginx 与 FPM 的工作机制

FPM的请求处理流程

　　从 FPM 接收到请求，到处理完毕，其具体的流程如下：

1. FPM 的 master 进程接收到请求2. master 进程根据配置指派特定的 worker 进程进行请求处理，如果没有可用进程，返回错误，这也是我们配合 Nginx 遇到502错误比较多的原因。3. worker 进程处理请求，如果超时，返回504错误4. 请求处理结束，返回结果

nginx转发请求给FPM

　　nginx 提供了 fastcgi 模块来将 http 请求映射为对应的 fastcgi 请求。nginx 的 fastcgi 模块提供了 fastcgi_param 指令来主要处理这些映射关系。具体见原文。

参考

• Nginx+Php-fpm运行原理详解
• PHP源码分析 - PHP-FPM运行原理
• 搞不清FastCgi与PHP-fpm之间是个什么样的关系
• 深入理解PHP之：Nginx 与 FPM 的工作机制