ADMIN Magazin Gestapelt - Schneller und sicherer mit RAID (Vorschau)

PHP-FPM
Netzwerk
Client
startet
(PHP-)Interpreter
führt aus
Client
Webserver
Webserver
TCP-Port 9000
Socket
PHP-FPM
Interpreter-Prozess
...
Interpreter-Prozess
Skript
Abbildung 1: Beim CGI-Standard startet der Webserver den Interpreter wie ein
ganz normales Kommandozeilenprogramm.
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.
zeit ü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.
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.
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.
www.admin-magazin.de
Admin
Ausgabe 06-2012
29