Table of Contents
Es gibt mehrere Arten wie PHP Dateien vom Web Server verarbeitet werden können. Die folgenden Bereiche beschreiben die bekanntesten Implementierungen:
mod_php
„mod_php“ ist ein Module für den Web-Server „apache“.
Mit diesem Modul ist PHP sozusagen „integriert“ im Web-Server. Das bewirkt, dass es keinen extra PHP-Prozess zur Abwicklung des PHP-Codes gibt sondern alles vom Apache-Prozess verarbeitet wird.
Der große Vorteil bei der Verwendung von „mod_php“ ist Performance. Im Vergleich zu CGI bewirkt der Umstieg auf „mod_php“ einen durchschnittlichen Performance-Gewinn von 300-500%.
Grund dafür ist die Möglichkeit des Cachings von diversen PHP-Modulen bzw. Konfigurationen die sonst (bei CGI und FastCGI) bei jedem Aufruf einer Seite immer neu ausgelesen und abgearbeitet werden müssen.
Wie erkenne ich, ob mod_php verwendet wird?
Nachdem mod_php ein Web-Server Modul ist muss es in der Webserver-Config wie folgt geladen werden (hier am Beispiel von Apache2)
LoadModule php7_module modules/mod_php.soAuf meinem Ubuntu Server war z.b. folgender Eintrag in der /etc/apache2/mods-available/php7.4.load vorhanden
LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.soDies führt dann typischerweise dazu, dass in der phpinfo() Ausgabe wie folgt darauf hingewiesen wird:
| Server API | Apache 2.0 Handler |
| Loaded Modules | core mod_so mod_watchdog http_core mod_log_config mod_logio mod_version mod_unixd mod_access_compat mod_alias mod_auth_basic mod_authn_core mod_authn_file mod_authz_core mod_authz_host mod_authz_user mod_autoindex mod_deflate mod_dir mod_env mod_filter mod_mime prefork mod_negotiation mod_php7 mod_reqtimeout mod_setenvif mod_status |
CGI
Die „Common Gateway Interface“ (kurz CGI) Implementation bedeutet, dass der Web-Server pro Anfrage eine neue PHP-Interpreter-Prozess startet. Dadurch müssen bei jeder Anfrage alle PHP-Module, die php.ini und die diversen anderen Konfigurationen neu geladen und durchgeführt werden, was sehr ineffizient ist.
Hauptvorteil von der CGI Implementation ist die komplette Isolierung zwischen ausgeführten Web-Server Code und PHP-Code.
FastCGI
FastCGI ist eine PHP-Implementation, die die Security-Vorteile von CGI implementiert aber trotzdem effizient in der Abarbeitung ist wie mod_php.
Hier wird nicht pro Request eine neue PHP-Interpreter-Instanz gestartet (was das primäre Problem war bei CGI), sondern es gibt schon „fertige“ PHP-Interpreter-Instanzen, denen nur die angefragte PHP-Datei übergeben wird.
Wie erkenne ich, ob FastCGI verwendet wird?
Serverseitig gibt es hier mehrere Möglichkeiten wie dies umgesetzt werden kann. Ein Beispiel wäre ein lokal verfügbares, ausführbares PHP Binary:
ScriptAlias /myPHP /home/devguide/php-install-directory
AddHandler cgi-php .php
Action cgi-php /myPHP/php-cgiHier ist also /home/devguide/php-install-directory/php-cgi ein spezielles PHP Binary für CGI Zwecke ist (sollte beim installieren von PHP automatisch mitkommen sollte oder als eigenes Package installiert werden kann).
In derphpinfo() Ausgabe sieht das ganze wie folgt aus:
| Server API | CGI/FastCGI |
FPM
Der „PHP-FastCGI Process Manager“ (kurz PHP-FPM) ist eine alternative zur FastCGI Implementation von PHP in einem Webserver.
Hier besteht immer parallel zum Web-Server Prozess (zu mindest) ein PHP-FPM Prozess, an den PHP-Anfragen vom Web-Server weitergeleitet werden.
Für weitere Details zu FPM siehe HIER
Source: https://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/
Wie erkenne ich, ob FPM verwendet wird?
FPM verwendet einen eigenen Service mit dem die FPM-Pools verwaltet werden. D.h. wenn man die Services des Servers sehen kann (z.b. über top oder htop) wird man recht schnell herausfinden, ob PHP-FPM verfügbar ist bzw. verwendet wird.
In derphpinfo() Ausgabe sieht das ganze wie folgt aus:
| Server API | FPM/FastCGI |
| php-fpm | active |
One Reply to “mod_php vs (Fast)CGI vs FPM”