Подтвердить что ты не робот

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

Я использую этот учебник для установки nginx, php и mysql на моем новом веб-сервере.

В учебном пособии используется ISPConfig 3, и есть возможность использовать FastCgi или PHP-FPM.

Мне интересно, что лучше двух. Что касается производительности и скорости, то какой из них лучше всего использовать inline с nginx?

Кстати, у меня также есть memcached и xcache на моем сервере.

4b9b3361

ОТВЕТЫ

Ответ 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 хорош для веб-сервера с наименьшим количеством бара.