PHP-Installationen im Vergleich

Scriptsprachen lassen sich auf vielerlei Arten mit dem HTTP-Server verbinden. Wie immer erhöht sich dabei mit der Komplexität der Installation auch die Zahl der zusätzlichen Aspekte, die man bedenken muss. In Bezug auf Webserver und Scriptsprachen gibt es drei wichtige Punkte, die miteinander vereinbart werden müssen: Geschwindigkeit, Sicherheit und Funktionalität. Während vor allem in Bezug auf Perl und das Apache-Modul mod_perl unzählige Artikel und Dokumente zur sicheren und performanten Installation verfügbar sind, wird PHP diesbezüglich ziemlich stiefmütterlich behandelt, auch wenn es zu einer der beliebtesten Scriptsprache im Web mit mehreren Millionen Installationen aufgestiegen ist. InfoWeek hat die Motorhaube geöffnet und die verschiedenen Anbindungsmethoden von PHP miteinander verglichen.

Für den mit knapp 70 Prozent Marktanteil verbreitetsten HTTP-Server Apache existieren grundsätzlich zwei verschiedene Anbindungsmethoden für PHP: Über das CGI (Common Gateway Interface) oder als Apache-Modul. Sowohl für die PHP-Entwickler als für die meisten Benutzer gilt das Apache-Modul (mod_php) dabei als "the way to go", die CGI-Variante wird als Notgroschen für minderbemittelte Webserver betrachtet. Auf den ersten Blick mag man diese Betrachtung sogar einigermassen teilen. Durch die Integration in Apache ist mod_php massiv schneller als die CGI-Variante, die komplette Funktionalität steht zur Verfügung und die Konfiguration ist dank APXS-Support trivial. Kein Wunder findet man auf den meisten Servern das PHP-Modul. Leider hat aber die Integration in den HTTP-Server Folgen in Bezug auf Sicherheit und Lastverhalten.
Durch die direkte Integration in Apache läuft PHP innerhalb des Apache-Prozesses. Dies hat zur Folge, dass es auch unter demselben Benutzer und derselben Gruppe agiert, beispielsweise nobody:nogroup. Somit hat man mit der Scriptsprache auf dieselben Bereiche Zugriff wie der HTTP-Server. Was auf den ersten Blick als unkritisch und gewollt erscheint, beispielsweise bei der Invokation von externen Programmen, kann bei grösseren Setups und mehreren Virtual Hosts unangenehm werden. So lässt sich problemlos von einem Virtual Host heraus auf einen anderen zugreifen. Das kann vom einfachen Lesen bis hin zur Modifikation oder Löschung der Daten gehen. Zwar lässt sich dies mit den PHP-Konfigurationsoptionen safe_mode und open_basedir einigermassen einschränken, leider verstossen diese beiden Optionen gegen grundlegende Regeln des Systemdesigns, indem man versucht, Sicherheit auf Applikationsebene zu erreichen, was auch entsprechende Folgen hat. So sind beide Sicherheitsfunktionen einerseits teilweise zu restriktiv und andererseits immer wieder defekt.

Ein weiteres Problem von mod_php ist das Lastverhalten. Der Master-Prozess des Apache Webservers (in der Version 1.x und 2.x in der Prefork-Ausführung) erzeugt zur Beantwortung der Requests mehrere Child-Prozesse, die für eine gewisse Anzahl von Requests am Leben bleiben. Dies hat unter anderem den Vorteil, dass bei einem Absturz eines Prozesses die anderen Prozesse nicht mit in den Orkus gerissen werden, allerdings auch den Nachteil, dass in jeden Prozess sämtliche Module eingelesen werden müssen, also auch PHP inklusive aller einkompilierten Extensions. Dadurch dauert das Starten eines Prozesses ungleich länger und der RAM-Verbrauch steigt bei einer höheren Anzahl von Apache-Prozessen exponentiell, selbst dann, wenn nur statische Dokumente oder Bilder ausgeliefert werden müssen. Um dieses Problem mindestens teilweise zu umschiffen, werden oft statische Dokumente und Bilder auf einem zweiten Server abgelegt, dessen HTTP-Server ohne irgendwelche Module daherkommt.