© saicle/Shutterstock.com
HHVM als alternative PHP-Engine im Einsatz

Goodbye LAMP-Stack


Die von Facebook entwickelte HHVM stellt viele der Paradigmen der Verarbeitung sowie Ausführung von PHP-Code auf den Kopf und bietet, neben einer erweiterten Syntax und zusätzlichen Sprachfeatures, vor allem eine deutliche Steigerung bei der Performance. Grund genug, die neue Laufzeitumgebung einmal in den eigenen Webstack zu integrieren.

Gut ein Jahr ist es her, dass wir im Zuge des Frühjahrsputzes unseren Webstack zuletzt entrümpelt haben: Aus dem alt gedienten Apache-Webserver wurde ein schlanker nginx und das vormals als Modul im Webserver integrierte PHP läuft seitdem als eigenständiger Prozess unter Verwendung von PHP-FPM (siehe gleichnamiger Kasten).

PHP-FPM

Der FastCGI-Prozessmanager geht auf einen bereits für PHP 4 verfügbaren Patch zurück, der die Möglichkeiten und die Kontrolle über PHP in FastCGI-Umgebungen verbessert, indem er PHP als eigenständigen Service etabliert und kontrolliert. Viele Dinge, die PHP out of the box nicht kannte, wurden möglich: So zum Beispiel das Starten der Worker-Prozesse mit unterschiedlichen UIDs/GIDs, der Einsatz in Chroot-Umgebungen oder mit individuellen php.ini-Optionen – ohne dabei den verpönten Safe Mode zu benötigen. Seit der Übernahme des Patches in den PHP-Kern mit der Version 5.3.3 erfreut sich der PHP-FPM steigender Beliebtheit und wird als die flexibelste und zugleich performanteste Art propagiert, PHP einzusetzen. Angesprochen wird PHP in einem solchen Setup aus dem Webserver heraus unter Verwendung des FastCGI-Protokolls und entweder via lokalem Socket oder über eine IP-Verbindung.

Zur Kommunikation zwischen Webserver und PHP kommt dabei folglich das FastCGI-Protokoll (siehe gleichnamiger Kasten) zum Einsatz, die Apache SAPI hat ausgedient.

FastCGI

Das Common Gateway Interface – kurz CGI – ist die „Plug-in“-Schnittstelle zu externen Programmen der Webserver und war in den Anfängen des Webs die bevorzugte Methode, externe Prozesse On Demand auszuführen und um dynamische Inhalte zu generieren. Da jedoch für jeden Seitenaufruf ein neuer, externer Prozess gestartet werden musste, wurde dieser Ansatz nicht zuletzt aus Gründen der Performance in der Breite durch andere Konzepte ersetzt. Im langjährigen Marktführer der Apache Group werden beispielsweise Erweiterungen bevorzugt als Module in den Server direkt integriert – obwohl auch hier natürlich weiterhin CGI funktioniert. So ist auch PHP klassischerweise als Modul ein- bzw. angebunden – das so genannte mod_php. Da beim Start des jeweiligen Serverprozesses jedoch nicht klar ist, welche Module zur Abarbeitung des Requests benötigt werden, wird auch dieses Konzept inzwischen zumeist eher kritisch gesehen. Zumindest wenn es um das Initiieren vergleichsweise teurer Module wie PHP, Python oder Perl geht.

Die Antwort auf die obigen Probleme liegt im bereits 1996 entworfenen FastCGI [1]: Anstatt für jede Anfrage einen neuen Prozess explizit zu starten, werden diese im Vorfeld bereits über einen externen Managementdienst instanziiert. Ein eingehender Web-Request kann so nach Bedarf an einen wartenden Prozess delegiert werden und der Webserver spart sich sowohl die unnötige Arbeit als auch Ressourcen für gar nicht verwendete Module.

Dieses Setup ermöglicht es uns, hochperformant vom Webserver aus sowohl via Socket mit einem lokal laufenden PHP-Stack in Kontakt zu treten, als auch über Systemgrenzen hinweg per IP-Verbindung. Das vor Kurzem von Facebook vorgestellte HHVM kann praktischerweise ebenfalls per FastCGI angesprochen und so direkt als Alternative zum klassischen PHP an den Webserver angebunden werden. Aufgrund der Flexibilität der Anbindung, die eine logische Trennung von Webserver und Runtime darstellt, ist es sogar möglich, PHP...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang