FastCgi vs PHP-FPM przy użyciu serwera WWW Nginx

Question

Używam tego tutorial do instalacji nginx, php i mysql na moim nowym serwerze internetowym.

Samouczek używa ISPConfig 3 i istnieje opcja, czy używać FastCgi czy PHP-FPM.

Zastanawiam się, który z nich jest lepszy. Pod względem wydajności i szybkości, który z nich najlepiej jest używać inline z nginx?

BTW, mam również memcached i włączone xcache na moim serwerze.

Answer 1

PHP-FPM jest znacznie lepszy niż stara obsługa języka FastCGI w PHP. Od PHP 5.3.3 PHP-FPM jest w rdzeniu, a stara implementacja FastCGI nie jest już dostępna.

Moja odpowiedź była tylko w dół głosowana (po tym, jak była przez jakiś czas online) i rozumiem dlaczego, więc oto lista, dla której PHP-FPM jest rzeczywiście lepsza niż stara implementacja FastCGI.

Przede wszystkim wiadomo było, że wdrożenie FastCGI jest złe w społeczności PHP. Strona iż dokumenty, które można znaleźć w https://wiki.php.net/ideas/fastcgiwork gdzie mówi:

php CGI jest przydatny w środowisku produkcyjnym bez dodatkowych „kule” (na przykład nasienie-fcgi z podziału lighttpd lub php FPM plastra). Projekt zakłada integrację takich "kul" i rozszerzenie php-cgi na obsługę różnych protokołów.

• daemonization (odłączyć, PID tworzenie plików, zmiennych środowiskowych Setup, setuid/setgid/chroot)
• wdzięcznego restartu
• oddzielną i poprawić warstwę transportową, aby umożliwić wsparcie dla różnych protokołów
• wsparcie dla protokołu SCGI
• wsparcie dla podzbioru protokołu HTTP
• ...

Oto lista rzeczy, które PHP-FPM nie lepiej, że został zabrany z http://php-fpm.org/about/:

• PHP daemonization: pid plik, plik dziennika, setsid(), setuid(), setgid(), chroot()
• Zarządzanie procesem. Możliwość "z gracją" zatrzymywania i uruchamiania pracowników PHP bez utraty jakichkolwiek pytań. Pozwala to na stopniową aktualizację konfiguracji i plików binarnych bez utraty jakichkolwiek zapytań.
• Ograniczanie adresów IP, z których mogą pochodzić żądania.
• Dynamiczna liczba procesów w zależności od obciążenia (odradzanie procesu adaptacyjnego).
• Uruchamianie pracowników z różnymi uid/gid/chroot/environment i różnymi opcjami php.ini (nie ma potrzeby trybu awaryjnego).
• Rejestrowanie STDOUT i STDERR.
• Możliwość awaryjnego restartu wszystkich procesów w przypadku przypadkowego zniszczenia pamięci podręcznej z pamięcią podręczną, jeśli używany jest akcelerator.
• Wymuszenie zakończenia procesu w przypadku niepowodzenia set_time_limit().

Dodatkowe funkcje: - Błąd nagłówek - Przyspieszone wsparcia przesyłanie - fastcgi_finish_request() - Slowlog z backtrace

Answer 2

Jedna mała korekta: PHP FastCGI SAPI jest nadal dostępny, nawet na 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 

Answer 3

Na stronie FastCGI:

1. FastCGI jest łatwiejsze do monitorowania: Jest jeden pid za użytkownika w FastCGI. Na serwerze internetowym z wieloma kontami łatwo jest znaleźć przeciążony proces. Z drugiej strony, php-fpm tworzy wiele procesów w zależności od żądań + jednego głównego procesu. Jest to kłopotliwe, gdy masz dużo połączeń z różnych adresów IP.
2. Konfiguracja Fastcgi jest łatwiejsza: Fastcgi jest zawarty w konfiguracji apache. Więc ułatwia to. Z drugiej strony, php-fpm wymaga dodatkowych plików konfiguracyjnych. Jeśli istnieją zależności konfiguracji, komplikuje to sytuację.
3. Duże dzielone firmy hostingowe nadal nie używają php-fpm w 2015 roku z php 5.6 Dziś wszystkie największe firmy hostingowe (bluehost, hostgator, namecheap) używają fastcgi, ale nie używają php-fpm, Myślę, że są powody, dla których nie oferują php-fpm jako php-handler.

Na stronie php-fpm:

1. Zauważyłem, że php-fpm spożywane 20% mniej niż FastCGI, które spożywane 20% mniej niż mod_php. Zatem php-fpm jest dobre dla serwera WWW z najmniejszą ilością pamięci RAM.