Der PHP-Interpreter PHP-FPM

© Matee Nuserm, 123RF

Ersatzspieler

Apache-Webserver führen PHP-Programme meist mit dem Modul Mod-php aus. Das offizielle PHP-Paket enthält aber auch noch eine wenig beachtete Alternative namens PHP-FPM. Dieser PHP-Interpreter nutzt die FastCGI-Schnittstelle und besitzt einige äußerst interessante Eigenschaften.
RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

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.

CGI-Beschleuniger

Webserver sind eigentlich von Haus aus recht dumme Gesellen. Sie können lediglich Dateien und somit statische Seiten ausliefern. Um eine Webseite dynamisch zu erzeugen, braucht der Webserver Hilfe von einem weiteren Programm – wie etwa dem PHP-Interpreter. Dieser führt dann wiederum eines oder mehrere (PHP-)Skripte aus, die schließlich die Seite zusammenklöppeln. Wie der Webserver den Interpreter aufrufen und dieser die fertige Seite zurückgeben muss, regelt seit 1993 ein Standard namens Common Gateway Interface, kurz CGI. Sobald eine Anfrage beim Webserver eingeht, setzt dieser ein paar Umgebungsvariablen und startet dann den Interpreter. Der wiederum wertet die Umgebungsvariablen aus und gibt die erzeugte Webseite über die Standardausgabe an den Webserver zurück. Abbildung 1 veranschaulicht das Zusammenspiel noch einmal.

Bei dieser Vorgehensweise startet der Webserver bei jeder Anfrage erneut den dicken Interpreter. Das frisst zum einen Rechenzeit und zum anderen auch Hauptspeicher. Häufig dauert das Laden des Interpreters sogar länger als die Ausführung des eigentlichen Skriptes. Um die Antwortzeiten zu erhöhen und den Server zu entlasten, entstand Mitte der 90er-Jahre die FastCGI-Schnittstelle [1]. Dabei startet der Interpreter genau einmal und läuft dann im Hintergrund ständig weiter.

Der Webserver reicht dann die Anfragen über einen TCP-Port oder einen Unix Domain Socket an den Interpreter weiter.

Da die Kommunikation über die bekannten Netzwerkstandards läuft, könnte der Interpreter sogar auf einem komplett anderen Rechner als der Webserver laufen. Die gesamte Umgebung lässt sich so wesentlich besser und einfacher skalieren.

»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.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Rechneranalyse mit Microsoft-Sysinternals-Tools

Der Rechner verhält sich eigenartig oder Sie haben eine unbekannte Applikation im Task Manager entdeckt und möchten erfahren, worum es sich dabei genau handelt und ob sie möglicherweise gefährlich ist? In so einem Fall helfen die Sysinternals-Tools von Microsoft. Dieser Beitrag stellt die drei Werkzeuge Autoruns, Process Explorer und TCPView vor. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018