it-swarm.com.ru

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

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

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

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

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

12
jaypabs

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

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

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

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

  • демонизация (отсоединение, создание 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() - Slowlog с backtrace

19
Fleshgrinder

Одно небольшое исправление: 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
6
Marian HackMan Marinov

на стороне fastcgi:

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

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

  1. я заметил, что php-fpm потребляет на 20% меньше, чем fastcgi, который потребляет на 20% меньше, чем mod_php. Итак, php-fpm хорош для веб-сервера с наименьшим количеством оперативной памяти.
0
Nicolas Guérinet