13

我正在使用本教程在我的新 Web 服务器上安装 nginx、php 和 mysql。

本教程使用 ISPConfig 3，并且可以选择使用 FastCgi 还是 PHP-FPM。

我想知道两者哪个更好。就性能和速度而言，这两者中哪一个最好用 inline 与 nginx 一起使用？

顺便说一句，我还在我的服务器上启用了 memcached 和 xcache。

4

3 回答 3

21

PHP-FPM 比 PHP 的旧 FastCGI 处理要好得多。从 PHP 5.3.3 开始，PHP-FPM 成为核心，旧的 FastCGI 实现不再可用。

我的回答刚刚被否决（在网上很长一段时间后），我明白为什么，所以这里列出了为什么 PHP-FPM 实际上比旧的 FastCGI 实现更好。

首先，FastCGI 的实现在 PHP 社区中很糟糕，这已经有一段时间了。可以在https://wiki.php.net/ideas/fastcgiwork找到的文档页面，其中显示：

如果没有额外的“拐杖”（例如来自 lighttpd 发行版的 spawn-fcgi 或 php-fpm 补丁），php-cgi 在生产环境中是没有用的。这个项目假设集成了这样的“拐杖”并扩展了 php-cgi 以支持不同的协议。

  • 守护进程（分离、创建 pid 文件、设置环境变量、setuid/setgid/chroot）
  • 优雅重启
  • 分离和改进传输层以支持不同的协议
  • 支持 SCGI 协议
  • 支持 HTTP 协议的子集
  • …</li>

以下是从http://php-fpm.org/about/获取的 PHP-FPM 做得更好的列表：

  • PHP守护进程setsid()：pid文件、日志文件、、、、、setuid()setgid()chroot()
  • 流程管理。能够“优雅地”停止和启动 PHP 工作者，而不会丢失任何查询。这允许在不丢失任何查询的情况下逐步更新配置和二进制文件。
  • 限制请求可以来自的 IP 地址。
  • 动态进程数，取决于负载（自适应进程生成）。
  • 使用不同的 uid/gid/chroot/environment 和不同的php.ini选项启动工作人员（不需要安全模式）。
  • 记录STDOUT和STDERR.
  • 如果使用加速器，可以在共享内存操作码缓存意外破坏的情况下紧急重启所有进程。
  • set_time_limit()如果失败则强制完成进程。

附加功能： - 错误标头 - 加速上传支持 - fastcgi_finish_request() - 带有回溯的慢日志

于 2013-06-17T07:25:25.960 回答
7

一个小的修正：PHP FastCGI SAPI 仍然可用，即使在 PHP 5.5.x 上也是如此。

[root@zulu1 ~]# /usr/local/php54/bin/php-cgi -v 
PHP 5.4.17 (cgi-fcgi) (built: Jul 18 2013 05:12:07) 
Copyright (c) 1997-2013 The PHP Group 
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
于 2013-07-18T11:07:37.873 回答
1

在 fastcgi 方面：

  1. Fastcgi 更容易监控：fastcgi 中每个用户有一个 pid。在具有许多帐户的 Web 服务器上，很容易找到过载的进程。另一方面，php-fpm 根据请求 + 一个主进程创建许多进程。当您有大量来自不同 IP 的连接时，这会很混乱。
  2. Fastcgi 配置更简单：Fastcgi 包含在 apache 配置中。所以它让事情变得更容易。另一方面，php-fpm 需要额外的配置文件。如果存在配置依赖关系，它会使事情变得复杂。
  3. 大型共享托管公司在 2015 年仍然不使用 php-fpm 和 php 5.6 今天，所有最大的共享网络托管公司（bluehost、hostgator、namecheap）都使用 fastcgi。我认为他们不提供 php-fpm 作为 php-handler 是有原因的。

在 php-fpm 方面：

  1. 我注意到 php-fpm 的消耗比 fastcgi 少 20%，fastcgi 比 mod_php 少 20%。因此，php-fpm 适用于内存最少的 Web 服务器。
于 2015-09-22T13:06:14.343 回答