Gacek Asked: 2014-11-21 02:31:22 +0800 CST2014-11-21 02:31:22 +0800 CST 2014-11-21 02:31:22 +0800 CST Fast-CGI、CGI、Mod-PHP、SuPHP、PHP-FPM 之间的区别和优势 772 有几个不同的 php“包装器”（？）。它们之间有什么区别？试图谷歌一些，但似乎无法找到信息。（mod-php 无法通过 Google 搜索）。 为什么我会选择一个而不是另一个？ php 1 个回答 Voted Best Answer Aleš Krajník 2014-11-21T03:05:58+08:002014-11-21T03:05:58+08:00 CGI 和 FastCGI 是两种非 PHP 特有的协议： CGI 脚本是一种在 HTTP 请求到达时运行服务器端脚本（不仅仅是 PHP！）的方法。在此设置中，Web 服务器为每个传入请求启动一个新的 CGI 进程，从而导致显着的性能开销。 FastCGI是一种“更好的 CGI”——为了解决 CGI 的局限性，FastCGI 作为服务器（TCP 或 UNIX）运行，因此可以跨请求重用资源。 启用 PHP 的网络服务器可以配置如下： mod_php是一个运行 PHP 的 Apache 模块。在此设置中，PHP 请求在 Apache 进程下处理，并附带所有相关内容：PHP 进程在 Apache 配置中定义，PHP 在 Apache 用户和权限下运行等。 PHP-FPM是 PHP 的 FastCGI 实现。在此设置中，PHP-FPM 作为独立的 FastCGI 服务器运行，Apache 使用 FastCGI 模块连接到它，例如mod_fcgid，mod_fastcgi或mod_proxy_fcgi(Apache 2.4+)。在这个配置中，权限、进程相关的东西和其他一切都由 PHP-FPM 服务器控制。性能与mod_php. SuPHP - 这用于解决mod_php与权限相关的一些缺点：mod_phpPHP 脚本在 Apache 用户/组下运行，但mod_suphp可以以不同用户身份运行脚本。suPHP 不再维护，不应使用。 CGI/FastCGI - 我根据评论中的问题添加了这个。在不知道设置细节的情况下，PHP 可以使用任何其他 FastCGI 实现作为 FastCGI 服务器运行 - 如另一个问题中所述。我不使用此设置，也没有看到比 PHP-FPM 有任何好处。 CGI - PHP 也可以作为优秀的 CGI 脚本运行，但我无法想象一个好的用例，除了与一些非常过时的环境兼容。 关于这些不同方法的优缺点，我只坚持mod_phpPHP-FPM，涵盖两个主要用例： mod_php在某些 Docker 设置中可能很有用，在这些设置中，您希望交付运行支持 PHP 的 Web 服务器的单个容器。一切都作为单个进程运行的事实使 Docker 容器配置更容易。另一方面，在带有 web 服务器的单个容器中运行 PHP-FPM 服务器将需要使用supervisord、高级 bash 脚本或其他方法进行流程编排，这与编写 Docker 容器的最佳实践背道而驰。 PHP-FPM 是一种更强大的方法，可以更好地分离关注点，因此 PHP-FPM 服务器可以独立于 Web 服务器进行配置、（性能）调整和维护。这也允许在池中或与 Web 服务器不同的机器上运行 PHP-FPM 服务器。如上所述，对于 Docker 容器，在这种情况下建议使用单独的 PHP-FPM 和 webserver 容器，使配置更复杂（更强大）。PHP-FPM 方法也是使用nginx网络服务器的唯一方法，因为它的 PHP 模块 AFAIK 不存在。 我的上述两种方法的 Docker 实现可以在这里找到： https://gitlab.com/craynic.com/docker/lap/ - 单一容器方法，将 PHP 7.4/8.0 作为 Apache 模块运行 https://gitlab.com/craynic.com/craynic.net/mvh - 一种多容器方法，将 PHP-FPM 与 Apache 网络服务器分离 该实现旨在与我的 Kubernetes 集群中的一些旧项目和新项目一起使用。随意使用它。 所以，TLDR： CGI、FastCGI 是协议；CGI 很慢，FastCGI 快得多 mod_php和 PHP-FPM 是运行 PHP 的两种主要方式 mod_SuPHP是一种用于解决mod_php缺点的方法。它已经过时，应该改用 PHP-FPM。
CGI 和 FastCGI 是两种非 PHP 特有的协议：
CGI 脚本是一种在 HTTP 请求到达时运行服务器端脚本（不仅仅是 PHP！）的方法。在此设置中，Web 服务器为每个传入请求启动一个新的 CGI 进程，从而导致显着的性能开销。
FastCGI是一种“更好的 CGI”——为了解决 CGI 的局限性，FastCGI 作为服务器（TCP 或 UNIX）运行，因此可以跨请求重用资源。
启用 PHP 的网络服务器可以配置如下：
mod_php是一个运行 PHP 的 Apache 模块。在此设置中，PHP 请求在 Apache 进程下处理，并附带所有相关内容：PHP 进程在 Apache 配置中定义，PHP 在 Apache 用户和权限下运行等。
PHP-FPM是 PHP 的 FastCGI 实现。在此设置中，PHP-FPM 作为独立的 FastCGI 服务器运行，Apache 使用 FastCGI 模块连接到它，例如
mod_fcgid，mod_fastcgi或mod_proxy_fcgi(Apache 2.4+)。在这个配置中，权限、进程相关的东西和其他一切都由 PHP-FPM 服务器控制。性能与mod_php.SuPHP - 这用于解决
mod_php与权限相关的一些缺点：mod_phpPHP 脚本在 Apache 用户/组下运行，但mod_suphp可以以不同用户身份运行脚本。suPHP 不再维护，不应使用。CGI/FastCGI - 我根据评论中的问题添加了这个。在不知道设置细节的情况下，PHP 可以使用任何其他 FastCGI 实现作为 FastCGI 服务器运行 - 如另一个问题中所述。我不使用此设置，也没有看到比 PHP-FPM 有任何好处。
CGI - PHP 也可以作为优秀的 CGI 脚本运行，但我无法想象一个好的用例，除了与一些非常过时的环境兼容。
关于这些不同方法的优缺点，我只坚持
mod_phpPHP-FPM，涵盖两个主要用例：mod_php在某些 Docker 设置中可能很有用，在这些设置中，您希望交付运行支持 PHP 的 Web 服务器的单个容器。一切都作为单个进程运行的事实使 Docker 容器配置更容易。另一方面，在带有 web 服务器的单个容器中运行 PHP-FPM 服务器将需要使用supervisord、高级 bash 脚本或其他方法进行流程编排，这与编写 Docker 容器的最佳实践背道而驰。PHP-FPM 是一种更强大的方法，可以更好地分离关注点，因此 PHP-FPM 服务器可以独立于 Web 服务器进行配置、（性能）调整和维护。这也允许在池中或与 Web 服务器不同的机器上运行 PHP-FPM 服务器。如上所述，对于 Docker 容器，在这种情况下建议使用单独的 PHP-FPM 和 webserver 容器，使配置更复杂（更强大）。PHP-FPM 方法也是使用nginx网络服务器的唯一方法，因为它的 PHP 模块 AFAIK 不存在。
我的上述两种方法的 Docker 实现可以在这里找到：
该实现旨在与我的 Kubernetes 集群中的一些旧项目和新项目一起使用。随意使用它。
所以，TLDR：
mod_php和 PHP-FPM 是运行 PHP 的两种主要方式mod_SuPHP是一种用于解决mod_php缺点的方法。它已经过时，应该改用 PHP-FPM。