Der PHP-Interpreter PHP-FPM

Wer in der PHP-Dokumentation das Kapitel zur Installation aufschlägt, stolpert als Erstes über das Apache-Modul »mod_php« . Es implantiert einen PHP-Interpreter in den Webserver Apache, der somit die PHP-Anwendungen selbst ausführen kann. Für Lighttpd und IIS beschreibt die Dokumentation einen PHP-Interpreter, der die FastCGI-Schnittstelle nutzt (siehe Kasten "CGI-Beschleuniger" ). Administratoren sollten hier jedoch nicht schon mit dem Lesen aufhören, sondern sich noch etwas weiter durch das Kapitel graben, bis sie auf den FastCGI Process Manager stoßen. Dahinter verbirgt sich ein alternativer PHP-Interpreter, der ein paar gravierende Nachteile von »mod_php« und des herkömmlichen FastCGI-Interpreters beseitigt.

»mod_php« ist zwar schnell eingerichtet und aktiviert, dafür läuft der Interpreter aber auch mit den Rechten des Webservers. Eine Änderung der Konfiguration erzwingt zudem einen Neustart des kompletten Webservers und sorgt so für einen Ausfall des Internetauftritts. »mod_php« skaliert zudem recht schlecht. Das bekommt man besonders zu spüren, wenn im Laufe der Zeit die Zugriffszahlen langsam ansteigen. Alle diese Nachteile waren auch Andrei Nigmatulin ein Dorn im Auge. Er entwickelte kurzerhand für den FastCGI-Interpreter einen Patch, der auch gleich noch ein paar vermisste Sicherheitsfunktionen nachrüstete. Dem so aufgebohrten Interpreter gab er den Namen FastCGI Process Manager oder kurz PHP-FPM [2] .

Sein Name ist dabei Programm: PHP-FPM startet gleich mehrere PHP-Interpreter-Prozesse, die ständig im Hintergrund laufen und auf Arbeit warten. Eingehende Anfragen nimmt PHP-FPM vom Webserver entgegen und verteilt sie an die PHP-Interpreter (siehe Abbildung 1 ).

Abbildung 1: Beim CGI-Standard startet der Webserver den Interpreter wie ein ganz normales Kommandozeilenprogramm.

Um Server-Ressourcen zu sparen, beendet PHP-FPM alle gerade nicht benötigten Interpreter-Prozesse und würgt zu lange vor sich hinwerkelnde PHP-Interpreter-Prozesse ab. Darüber hinaus kann man die Konfiguration im laufenden Betrieb ändern, ohne einen Interpreter-Prozess oder gleich den ganzen Webserver neustarten zu müssen. Darüber hinaus bietet PHP-FPM erweiterte Log-Funktionen. So kann es beispielsweise alle Skripte protokollieren, die eine bestimmte Rechenzeit überschritten haben – inklusive der verursachenden PHP-Funktion. Das hilft nicht nur bei der Fehlersuche während der Entwicklung, sondern deckt auch Angriffe auf.

Richtig gepoolt

Die PHP-Interpreter-Prozesse lassen sich zu sogenannten Pools zusammenfassen. Jeder Pool kann dabei eine eigene PHP-Konfiguration besitzen und seine Prozesse sogar in eine Chroot-Umgebung einsperren. Darüber hinaus darf der Administrator festlegen, unter welchem Benutzerkonto die Prozesse eines Pools vor sich hinwerkeln. Eingehende Anfragen lassen sich dann gezielt an einen der Pools weiterreichen. Damit könnte man beispielsweise einen maßgeschneiderten Pool für das Blog, einen weiteren für das Forum und einen dritten für die offizielle Website abstellen.

Da jeder Pool die Anfragen auf einer eigenen TCP-Adresse entgegennimmt, kann man bei steigender Last der Forums-Website den zugehörigen Pool auf einen eigenen, leistungsfähigeren Rechner auslagern – dazu sind nur ein paar einfache Änderungen in den Konfigurationsdateien notwendig.

Abbildung 2: Der Webserver reicht entweder über einen TCP-Port oder einen Unix Socket die Anfrage an PHP-FPM weiter, der sie von einem PHP-Interpreter-Prozess abarbeiten lässt.

PHP-FPM kommt sogar mit Zusatzmodulen wie eAccelerator oder APC zurecht, die den vom PHP-Interpreter kompilierten Quelltext (Opcodes) puffern. Dies spart bei der nächsten Anfrage eine erneute Übersetzung, was wiederum den Seitenaufbau beschleunigt. Ein Interpreter-Prozess kann den Opcode-Cache jedoch (versehentlich) überschreiben oder zerstören. PHP-FPM überwacht deshalb den Cache und startet sich bei Amok laufenden Prozessen automatisch einmal neu.

Startrampe

Seit PHP 5.4.0 gehört PHP-FPM zum offiziellen PHP-Paket und liegt damit auch den meisten aktuellen Linux-Distributionen bei. Ein entsprechendes Paket findet man leicht über den Paketmanager, meistens heißt es »php5-fpm« . Eine der wenigen Ausnahmen ist noch Debian 6 (Squeeze). Dort kann man jedoch PHP-FPM über das Dotdeb-Repository hinzuholen, indem man in »/etc/apt/sources.list« die Zeile:

deb http://packages.dotdeb.org stable all

ergänzt. Das benötigte Paket installiert dann:

apt-get update
apt-get install php5-fpm

Da man die von den Pools verwendeten TCP-Ports frei vergeben kann, lässt sich PHP-FPM übrigens auch parallel zu anderen FastCGI-Interpretern betreiben.

PHP-FPM ist im Moment auf Linux zugeschnitten, weshalb es im Windows-Paket von PHP fehlt. Die dort enthaltene »php-cgi.exe« ist nur der herkömmliche FastCGI-Interpreter. Windows-Administratoren müssen daher entweder PHP-FPM umständlich in einer Cygwin-Umgebung per Hand übersetzen und in Betrieb nehmen oder aber PHP-FPM getrennt vom Webserver auf einem eigenen Linux-Rechner laufen lassen. Die letztere Variante ist dabei die weitaus einfachere, zumal man das Linux-System mit PHP-FPM auch in eine virtuelle Maschine verbannen kann. Im Folgenden soll daher weiterhin die Inbetriebnahme unter Linux im Vordergrund stehen.

Sämtliche Konfigurationsdateien für PHP-FPM und seine PHP-Interpreter-Prozesse sammelt das Verzeichnis »/etc/php5/fpm« (vorausgesetzt ,die eigene Distribution gibt nicht andere Verzeichnisse vor). Die Einrichtung von PHP-FPM geschieht in der Konfigurationsdatei »php-fpm.conf« . Im einfachsten Fall weist in ihr nur die einsame Zeile:

include=/etc/php5/fpm/pool.d/*.conf

darauf hin, wo alle weiteren Konfigurationsdateien zu finden sind. Kommentare beginnen übrigens immer mit einem Semikolon und gehen bis zum Ende der Zeile. Anstelle der »php-fpm.conf« findet man häufig auch eine Beispieldatei, unter Open Suse heißt sie »php-fpm.conf.default« . Diese muss man dann lediglich korrekt umbenennen, eine Anpassung ist normalerweise nicht notwendig.