FastCgi vs PHP-FPM с использованием веб-сервера Nginx

Ответ 1

PHP-FPM намного лучше, чем старая FastCGI-обработка PHP. Начиная с PHP 5.3.3 PHP-FPM находится в ядре, а старая реализация FastCGI больше не доступна.

Мой ответ был просто проголосован (после того, как он был в сети в течение довольно долгого времени), и я понимаю, почему, так вот список, почему PHP-FPM на самом деле лучше, чем старая реализация FastCGI.

Прежде всего, довольно давно было известно, что реализация FastCGI плоха в сообществе PHP. Страница, на которой есть документы, которые можно найти в https://wiki.php.net/ideas/fastcgiwork, где говорится:

php-cgi не полезен в производственной среде без дополнительных "костылей" (например, spawn-fcgi из lighttpd distribution или php-fpm patch). Этот проект предполагает интеграцию таких "костылей" и расширение php-cgi для поддержки разных протоколов.

• daemonization (отключение, создание файла pid, переменные среды установки, setuid/setgid/chroot)
• изящный перезапуск
• разделить и улучшить транспортный уровень, чтобы поддерживать различные протоколы.
• поддержка протокола SCGI
• поддержка подмножества протокола HTTP
• ...

Вот список того, что PHP-FPM делает лучше, чем в http://php-fpm.org/about/:

• Демонстрация PHP: файл pid, файл журнала, setsid(), setuid(), setgid(), chroot()
• Управление процессами. Возможность "изящно" останавливать и запускать PHP-работников без потери запросов. Это позволяет постепенно обновлять конфигурацию и бинарные файлы без потери запросов.
• Ограничение IP-адресов, из которых могут поступать запросы.
• Динамическое число процессов в зависимости от нагрузки (адаптивный процесс нерест).
• Запуск рабочих с разными настройками uid/gid/chroot/environment и различными параметрами php.ini (нет необходимости в безопасном режиме).
• Запись STDOUT и STDERR.
• Возможность экстренного перезапуска всех процессов в случае случайного уничтожения кеша кода операции общей памяти при использовании ускорителя.
• Задание завершения процесса, если set_time_limit() не работает.

Дополнительные возможности: - Заголовок ошибки - Ускоренная поддержка загрузки - fastcgi_finish_request()- Медленный ход с backtrace

Ответ 2

Одна небольшая коррекция: PHP FastCGI SAPI по-прежнему доступен даже на PHP 5.5.x.

[[email protected] ~]# /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

Ответ 3

На стороне fastcgi:

• Fastcgi легче отслеживать: В fastcgi есть один pid для каждого пользователя. На веб-сервере со многими учетными записями легко найти перегруженный процесс. С другой стороны, php-fpm создает много процессов в зависимости от запросов + один мастер-процесс. Это беспорядочно, когда у вас много соединений с разных IP-адресов.
• Конфигурация Fastcgi проще: Fastcgi включен в конфигурацию apache. Таким образом, это упрощает работу. С другой стороны, php-fpm требует дополнительных файлов конфигурации. Если есть зависимости конфигурации, это усложняет ситуацию.
• Большие хостинговые компании по-прежнему не используют php-fpm в 2015 году с php 5.6 Сегодня все крупнейшие общедоступные веб-хостинговые компании (bluehost, hostgator, namecheap) используют fastcgi, но они не используют php-fpm, я думаю, есть причины, по которым они не предлагают php-fpm в качестве php-обработчика.

На стороне php-fpm:

• Я заметил, что php-fpm потребляется на 20% меньше, чем fastcgi, который потребляет на 20% меньше, чем mod_php. Таким образом, php-fpm хорош для веб-сервера с наименьшим количеством бара.