FastCgi vs PHP-FPM utilizzando il server Web Nginx

Question

Sto utilizzando questo tutorial per installare nginx, php e mysql sul mio nuovo server web.

Il tutorial utilizza ISPConfig 3 e c'è un'opzione per utilizzare FastCgi o PHP-FPM.

Mi chiedo quale sia il migliore dei due. In termini di prestazioni e velocità, quale dei due è il migliore da usare in linea con nginx?

BTW, ho anche memcached e xcache abilitato sul mio server.

Answer 1

PHP-FPM è molto meglio della vecchia gestione FastCGI di PHP. A partire da PHP 5.3.3 PHP-FPM è nel core e la vecchia implementazione FastCGI non è più disponibile.

La mia risposta è stata appena votata (dopo essere stata online per un po 'di tempo) e ho capito perché, ecco un elenco perché PHP-FPM è in realtà migliore della vecchia implementazione FastCGI.

Prima di tutto, era noto da un po 'di tempo che l'implementazione FastCGI non è buona nella comunità PHP. Una pagina che i documenti che possono essere trovati in https://wiki.php.net/ideas/fastcgiwork in cui si dice:

php-cgi non è utile in ambiente di produzione senza ulteriori “stampelle” (ad esempio uova-fcgi dalla distribuzione lighttpd o una patch php-FPM). Questo progetto presuppone l'integrazione di tali "stampelle" e l'estensione di php-cgi per supportare diversi protocolli.

• daemonization (staccare, la creazione di pid del file, le variabili di ambiente di configurazione, setuid/setgid/chroot)
• grazioso riavvio
• separata e migliorare il livello di trasporto per consentire il supporto per diversi protocolli
• il supporto per il protocollo SCGI
• supporto per sottoinsieme del protocollo HTTP
• ...

Ecco una lista delle cose che PHP-FPM fa meglio che è stato preso da http://php-fpm.org/about/:

• PHP daemonization: file di pid, file di log, setsid(), setuid(), setgid(), chroot()
• Gestione dei processi. Capacità di "garbo" interrompere e avviare i worker PHP senza perdere alcuna query. Ciò consente di aggiornare gradualmente la configurazione e il binario senza perdere alcuna query.
• Restrizione degli indirizzi IP da cui possono provenire le richieste.
• Numero dinamico di processi, a seconda del carico (generazione di processo adattativa).
• Avvio dei lavoratori con diversi uid/gid/chroot/environment e diverse opzioni php.ini (non è necessario per la modalità provvisoria).
• Registrazione STDOUT e STDERR.
• Possibilità di riavviare in emergenza tutti i processi in caso di distruzione accidentale della cache dell'opcode della memoria condivisa, se si utilizza un acceleratore.
• Forzare il completamento del processo se set_time_limit() non riesce.

caratteristiche: - Errore intestazione - Accelerated upload di sostegno - fastcgi_finish_request() - Slowlog con backtrace

Answer 2

Una piccola correzione: il PHP FastCGI SAPI è ancora disponibile, anche su 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

Sul lato fastcgi:

1. FastCGI è più facile da controllare: C'è un pid per utente in fastcgi. Su un server web con molti account è facile trovare un processo sovraccarico. D'altra parte, php-fpm crea molti processi a seconda delle richieste + un processo principale. Questo è complicato quando si hanno molte connessioni da diversi IP.
2. La configurazione di Fastcgi è più semplice: Fastcgi è incluso nella configurazione di Apache. Quindi rende le cose più facili. D'altra parte, php-fpm richiede ulteriori file di configurazione. Se ci sono dipendenze di configurazione rende le cose complicate.
3. Le grandi società di hosting condivise ancora non usano php-fpm nel 2015 con php 5.6 Oggi, tutte le più grandi società di hosting web condivise (bluehost, hostgator, namecheap) usano fastcgi ma non usano php-fpm, Penso che ci siano ragioni per le quali non offrono php-fpm come gestore php.

Sul lato php-fpm:

1. Ho notato che php-fpm consumato 20% meno di fastcgi che consuma il 20% in meno rispetto mod_php. Quindi, php-fpm è buono per il web server con la più piccola quantità di ram.