Vergleich der Anbindung von PHP als Apache-Modul CGI und FastCGI (de)
From RootForum Community » Wiki
Contents |
Einleitung
Der Einsatz von PHP ist angesichts der weiten Verbreitung und der Einsteigerfreundlichkeit sehr beliebt unter Entwicklern und so gut wie jeder Hoster bietet Webspace-Pakete mit bereits installiertem PHP4 bzw. PHP5 an.
Jedoch lässt sich PHP nur bedingt steuern und gerade bei vielen Projekten die betreut werden, bietet sich irgendwann der Wechsel auf einen Managed- bzw. Root-Server an. Nun ist man bei einem Root-Server angelangt und möchte natürlich möglichst schnell diesen in den Produktiveinsatz bringen, aber dort fangen die Fragen bereits an. PHP gibt es als Server-Modul etwa für Apache, aber man wird relativ schnell darauf stoßen, dass es PHP auch auf CGI-Basis gibt. Welche Vor- bzw. Nachteile ein PHP auf CGI-Basis bietet oder wann welcher Typ empfehlenswert ist, versucht dieser Artikel zu beleuchten.
Hinweis
Der Inhalt dieses Artikels wurde an Hand von eigenen Erfahrungen und mehrfachen Beiträgen aus dem rootforum.de erstellt. Bei Fragen oder Verbesserungsvorschlägen bitte eine PM an mich.
Die Varianten kurz erläutet
| Apache-Modul | Die verbreiteste Lösung, PHP auf einem Webserver verfügbar zu machen, stellt mod_php dar. Es besticht durch seine relativ einfache Installation, Konfiguration, Wartung und Performance. |
| SuPHP | Mit Hilfe von suPHP, einem Modul für den Apache-Webserver, lassen sich PHP-Skripte mit dem Benutzer ausführen, dem diese auch gehören. Der Sicherheitsaspekt spielt hierbei die größte Rolle. |
| FastCGI (+ SuExec) | Die mangelnde Performance von PHP via SuPHP zwingt viele zum Einsatz von mod_php. FastCGI erreicht für gewöhnlich nahezu die selbe Performance von mod_php mit der Sicherheit von SuPHP und weist zudem flexiblere Einsatzmöglichkeiten auf. |
mod_php im Detail
Wir wollen uns einmal etwas genauer mit mod_php und seinen Vor- und Nachteilen beschäftigen. Als wesentliche Punkte werden u.a. aufgeführt:
Vorteile:
- Sehr einfache Installation im Gegensatz zur anderen Lösungen
- Konfiguration und Wartung hält sich beim Aufwand in Grenzen
- Sehr gute Performance (allerdings zu lasten der Auslieferung rein statischer Daten)
Nachteile:
- PHP-Skripte werden mit den Rechten des Webservers ausgeführt, dies stellt evtl. ein erhebliches Sicherheitsrisiko dar, da die Skripte somit auf alle Dateien zugreifen dürfen, die dem Webserver gehören.
- Man kann immer nur exakt eine PHP-Version verwenden (ohne den Quellcode von PHP zu ändern)
- Die Konfiguration von PHP wird global geregelt, kann aber (eingeschränkt) mit einer .htaccess-Datei geändert werden. Wenn die Konfiguration von PHP in der Apache-Konfiguration anstatt einer .htaccess-Datei erfolgt, stehen alle Konfigurationsmöglichkeiten zur Verfügung.
PHP via suPHP im Detail
suPHP stellt die gängigste Lösung zum Einsatz von PHP auf CGI-Basis dar. Hierbei steht vorallem die Sicherheit im Mittelpunkt.
Vorteile:
- Es lassen sich PHP-Versionen kombinieren (anhand der Dateiendung)
- Die Skripte werden mit den Rechten des Benutzers, etwa webXYZ123, an Stelle des Webserver-Benutzers ausgeführt
Nachteile:
- Die Performance ist massiv schlechter im Vergleich zu mod_php, da PHP bei jedem Aufruf in den Speicher geladen und anschließend wieder entladen werden muss
- Die Konfiguration von PHP wird mehr oder weniger global geregelt (eigene php.ini pro Verzeichnis/Domain/Benutzer ist aber möglich).
PHP via FastCGI mit suexec
Die Performanceprobleme von PHP via suPHP liegt vielen schwer im Magen. FastCGI mit suexec versucht die Vorteile von mod_php und suPHP zu kombinieren.
Vorteile:
- PHP erreicht nahezu die selbe Performance wie auf Basis von mod_php
- Es lassen sich pro VirtualHost beliebig viele PHP-Prozesse spawnen, die fest im Speicher bleiben
- PHP-Prozesse von niedrig frequentierten Seiten lassen sich via nice unterpriorisieren und umgekehrt
- Man kann pro VirtualHost ein eigenes PHP-Binary (beliebige Version) zugänglich machen
- Die Konfiguration kann pro VirtualHost geregelt werden
- Die Skripte werden mit den Rechten des Benutzers, etwa webXYZ123, an Stelle des Webserver-Benutzers ausgeführt
- Nutzung des mpm-workers an Stelle des veralteten mpm-prefork, Performancevorteil für statische Inhalte
Nachteile:
- Kompliziertere Installation als suPHP oder mod_php
- Konfiguration von suexec, um die Skripte mit den Rechten des Besitzers auszuführen, kann nicht wie bei Einsatz von suPHP "on the fly" verändert werden, sofern nicht ein gepatchtes SuExec-Binary genutzt wird.
- Die Wartung eines Systems auf FastCGI lässt teilweise zu wünschen übrig
- Viele FastCGI-Implementierungen (mod_fastcgi/mod_fcgid beim Apache oder mod_fastcgi bei lighttpd) haben Kinderkrankheiten, die bei vielen Requests bzw. einem ausgelasteten System auftreten.
Welche Variante für wen?
Es gibt nicht die eine, einzig wahre Lösung und die wird es nie geben. Welches System auf welche Bedürfnise am Besten passt, muss jeder für sich entscheiden bzw. ausprobieren. Um die Entscheidung zu erleichtern, werden nachfolgend Schwerpunkte aufgeführt.
PHP als Apache-Modul
- + Für Anfänger empfohlen, auf Grund seiner Einfachheit
- + Sehr gute Performance
- + Bei Webservern, die nur eine Präsenz ausliefern und daher die bestmögliche Performance benötigen
- - Führt PHP-Skripte mit den Rechten des Webservers aus
PHP via suPHP
- + Bietet ehrheblich mehr Sicherheit, da Skripte mit den Rechten des Besitzers ausgeführt werden
- + suPHP lässt sich jederzeit (um-)konfigurieren
- - Schlechte Performance
PHP via FastCGI mit SuExec
- + Sehr gute Performance
- + Internetpräsenzen lassen sich priorisieren
- + Beliebig viele PHP-Binaries inkl. individueller Konfiguration
- + PHP-Skripte werden mit den Rechten des Besitzers ausgeführt
- - Schwere Installation/Konfiguration/Wartung
- - Konfiguration von suexec nicht "on the fly" möglich
- - Durch die Komplexität des Protokolls größere und kleinere Bugs in den FastCGI-Implementierungen
Fazit
Wie bereits erwähnt, gibt es nicht die perfekte Lösung, die überall passt. Wer einen Root-Server betreibt, sollte sich trotzdem Gedanken über den gewünschten Typ seiner PHP-Installation machen, da diese einerseits sicherheitstechnisch verschieden sind und andererseits einen unterschiedlich hohen Grad der Benutzerfreundlichkeit für den Endanwender bieten. Es ist jedoch zu bedenken, dass dieses HowTo nicht perfekt ist und es nie sein wird (dies liegt den Dingen allgemein zu Grunde), jedoch wird versucht, es möglichst aktuell und korrekt zu halten. Ein Blick auf andere Seiten, die jeweils die einzelnen Varianten diskutieren, kann auf keinen Fall schaden.
