PHP-Installationen im Vergleich

PHP als Modul oder über das CGI mit dem Webserver verbinden?

30. April 2004

CGI: Langsamer geht es nimmer

PHP als CGI löst immerhin das Sicherheitsproblem. Die Ausführung der PHP-Binaries lässt sich mit dem Suexec-Wrapper ahnlich wie bei mod_perl kontrollieren. Damit werden die PHP-Scripts nicht mehr unter der UID und GID des Webservers sondern des jeweiligen Benutzers ausgeführt. Auch lässt sich der Zugriff auf den Verzeichnisbaum kontrollieren. Die Konfiguration ist leider nicht ganz einfach, so wird ein PHP-Wrapper (mod_cgiwrap o.ä.) benötigt, damit man das PHP-Binary nicht unterhalb des Apache-Document-Roots ablegen (Sicherheitsrisiko) oder per Shebang-Zeile (#! /usr/local/php/ bin/php) aufrufen muss.

Eine Alternative ist mod_suphp, ein Modul, das sich ähnlich wie mod_php über APXS in den HTTP-Server einhängt und dann selber das PHP-Binary aufruft. Dies macht zwar die Konfiguration leichter und benötigt kein Suexec, leider ist eine Limitierung auf bestimmte Verzeichnisbäume nicht möglich. Dies ist nicht wirklich erwünscht, da so die Anwender ebenfalls durchs Dateisystem surfen können.

Bezüglich Geschwindigkeit sieht es bei der CGI-Variante schlechter als beim Modul aus. Da für jeden Request und nicht für jeden Prozess eine neue Instanz des PHP-Interpreters geladen werden muss, steigt die Workload noch weiter an und die Anzahl Requests pro Sekunde, welcher der Webserver beantworten kann, sinkt entsprechend.

Wunderwaffe FastCGI

Wie der Name schon sagt, möchte FastCGI die Ausführung von Software über das CGI beschleunigen. Dabei wird anstatt der Scriptsprache mod_fastcgi in den Webserver geladen, das dann nachher die Verbindungsbrücke zur Scriptsprache darstellt und das Prozessmanagement übernimmt. Die Funktionsweise erinnert dabei ein wenig an das Prinzip der Applikationserver. FastCGI startet bei der Initialisierung des Webservers eine vorbestimmte Anzahl von PHP-Prozessen, die dann im RAM gehalten werden und an die der Code durchgereicht wird, wenn ein PHP-Script ausgeführt werden muss. Ist das Script ausgeführt, verbleibt der PHP-Prozess im RAM und wartet auf den nächsten Request, bis das Ende seiner Lebenszeit erreicht ist und ein neuer PHP-Prozess gestartet wird. Auf diese Weise wird die Workload viel kleiner gehalten, da nicht für jeden Request ein neuer PHP-Prozess gestartet werden muss und der HTTP-Server vom Ballast befreit wurde. So können statische Dokumente und Bilder massiv schneller ausgeliefert werden und das Lastverhalten verbessert sich.

Auch lässt sich mit Hilfe von FastCGI die Ausführung der PHP-Scripts auf andere Maschinen verteilen, womit der Webserver nur noch für das Ausliefern der Daten zuständig ist und die Ausführung der Scripts auf speziell dafür eingerichteten Maschinen stattfindet.
Bezüglich der Sicherheit muss man sich bei FastCGI auch kaum Sorgen machen: Mit Hilfe der FastCgiWrapper-Direktive lässt sich die Script-Ausführung mit Suexec kontrollieren.

Modul, CGI und FastCGI im Überblick

Apache 1.3.x oder 2.x?

Auch wenn der Apache-Webserver in der Version 2 schon vor langer Zeit veröffentlicht wurde, setzen noch die meisten Administratoren auf den alten 1.3.x-Zweig. Dies vor allem deshalb, weil der Anreiz zum Wechsel fehlt. Da die meisten PHP-Extensions nicht Thread-safe sind, kommt der Einsatz von mod_php mit Apache 2 und einem threadenden MPM, das ressourcenschonender und schneller als das alte Prefork-Modell arbeitet, Russischem Roulette sehr nahe.

Möchte man auf mod_php setzen, sollte man entweder bei der alten Version bleiben oder darauf achten, Apache 2 mit dem Prefork-MPM einzusetzen. Bei der Verwendung von PHP über das CGI ist der Einsatz mit einem threadenden Apache, beispielsweise mit dem Worker-MPM, ungefährlich. Vom Einsatz der als Suexec-Ersatz gedachten MPMs wie Perchild oder Metux-MPM muss bislang noch abgeraten werden. Perchild ist auf einigen Plattformen, darunter Linux, sehr instabil und wird nicht mehr weiter gepflegt. Metux-MPM befindet sich momentan noch in der Testphase und ist ebenfalls instabil.