Der Weg zur Tanzfläche

Veröffentlicht am 11. Februar 2010 (vor 1195 Tagen)

Es wurde schon viel darüber spekuliert, wie groß der Anteil der PHP-Nutzer ist, die von HipHop profitieren werden. Die Zahlen bewegen sich im Wesentlichen zwischen 0% und 100%, daher versuche ich mich gar nicht erst an einer eigenen Schätzung, sondern will stattdessen über die Voraussetzungen schreiben, die ein Team beziehungsweise eine Firma erfüllen muss, um von HipHop profitieren zu können.

Stand heute unterstützt HipHop keine PHP 5.3-Features, und auch nicht gewisse PHP 5.2-Features wie eval(). Ganz abgesezen davon, dass man evil sowieso nicht verwenden sollte, kann man also nicht einfach davon ausgehen, dass beliebiger PHP-Code mit HipHop funktioniert. Das bedeutet, dass das Festlegen und Überwachen von Coding Guidelines für Teams, die HipHop einsetzen wollen, noch wesentlich wichtiger wird, als es heute ohnehin schon ist.

Fast identisch

Es wird immer Unterschiede in den Funktionalitäten von HipHop und PHP geben, da sich PHP weiterentwickelt und neue Features eingeführt werden, die HipHop nachbilden muss. HipHop wird also immer ein wenig hinterher sein. Das ist normalerweise kein Problem, außer man ist auf die Benutzung von bestimmten neuen Features der neuesten PHP-Version angewiesen. Wenn man Code für HipHop schreiben will, muss man also defensiv programmieren.

HipHop führt PHP aus, ohne dass die Zend Engine beteiligt ist. Es gibt daher keine Garantie, dass sich ein Programm unter PHP und HipHop identisch verhält. Daher braucht man automatisierte Unit- und Integrationstests, um die Ergebnisse unter PHP und HipHop zu vergleichen, und herauszufinden, ob Abweichungen einen Fehler bedeuten oder hinnehmbar sind.

Ein bißchen anders

Es ist nicht realistisch, anzunehmen, dass eine größere Codebasis, die zur Zeit unter PHP läuft, unter HipHop exakt die gleichen Ergebnisse liefert. Die Ergebnisse können sich beispielsweise schon aufgrund von unterschiedlichen impliziten Sortierreihenfolgen unterscheiden. Auch (oder gerade) wenn man mit automatischen Tests die Ergebnisse unter PHP und unter HipHop vergleicht, müssen die Testsuites mit diesen Unterschieden umgehen können. Das bedeutet, dass eine flexible Softwarearchitektur notwendig wird, in der Dependency Injection und damit der Einsatz von Mock-Objekten möglich ist.

Auf längere Sicht, werden C++-Skills und -Entwicklungswerkzeuge benötigt, denn die bekannten PHP-Werkzeuge wie xdebug sind unter HipHop nicht verfügbar, da ja bei der eigentlichen Code-Ausführung auf dem Produktivserver kein PHP mehr beteiligt ist. Es wird schwierig, wenn nicht sogar unmöglich, beim Debugging des C++-Codes herauszufinden, was der entsprechende PHP-Code ist. Und wenn ich von meinen eigenen C++-Kenntnissen ausgehe, dann ist an Debugging gar nicht erst zu denken. Ich fürchte, das wird den meisten Teams, die PHP entwickeln, so gehen.

Da PHP unter fast jedem Webserver läuft, kann man das gleiche Skript problemlos auf einem Intel- oder AMD-Prozessor oder auch einem anderen Betriebssystem ausführen. Der PHP-Code, zumindest wenn man sorgfältig programmiert hat, ist im Wesentlichen von der tatsächlichen Systemumgebung abstrahiert.

Mehr Komplexität

HipHop erzeugt C++-Code, der wiederum in hoch optimierten Maschinencode übersetzt wird. Dabei spielt die Prozessorarchitektur aber plötzlich wieder eine wichtige Rolle. Man kann die Software nicht nur einmal übersetzen, sondern muss sie für jede Zielarchitektur neu übersetzen und optimieren. Mit HipHop muss man also entweder die Architektur der eingesetzten Server vereinheitlichen, oder eine Compile-Farm aufbauen, die den Code für die verschiedenen Server-Architekturen cross-kompiliert. Das Kompilieren einer größeren Codebasis kann ziemlich lange dauern, und jede winzige Änderung an der Software macht eine erneute Übersetzung nötig.

Es ist also auch nicht mehr möglich, einige wenige veränderte PHP-Skripte zu deployen, sondern man muss ein einziges, monolithisches Binary veröffentlichen. Das bedeutet, dass komplexere Build- und Deployment-Prozesse etabliert werden müssen. Apache und Lighty sind keine Option mehr, da HipHop einen eigenen Webserver mitbringt. Das gesamte Load-Balancing, Caching, Proxying und URL-Rewriting, das heute im Webserver stattfindet, muss angepasst werden.

HipHop reduziert die Systemlast. Das bedeutet aber nicht automatisch kürzere Antwortzeiten für die Nutzer einer Website, denn die Ein- und Ausgaben bestimmten im Wesentlichen die Antwortzeit. Im Vergleich zur Ausführung von PHP-Code dauert der Zugriff auf eine Disk oder auf das Netzwerk sehr, sehr lang. In den meisten Fällen ist es so, dass bei der Ausführung einer PHP-Anwendung der Computer einen Großteil der Zeit damit verbringt, auf das Laden oder Speichern von Daten von/auf einer externen Quelle zu warten.

Umdenken

Selbst wenn HipHop auch bei den Ein- und Ausgaben schneller ist als PHP, werden dadurch weder Disks noch das Netzwerk schneller. Man kann also dank HipHop mit der gleichen Anzahl Server mehr gleichzeitige Requests verarbeiten, oder natürlich weniger mit weniger Servern die gleiche Anzahl von Requests verarbeiten. Die interessante Frage ist nun, ob die I/O-Backends, die ja ohnehin in den allermeisten Fällen die Performance-Bottlenecks sind, mit dem erhöhten Traffic überhaupt zurechtkommen. Es ist gut möglich, dass man sein Skalierungsproblem nur verschoben hat. Um die richtigen Maßnahmen zur Skalierung zu ermitteln, muss man den Code durch sorgfältiges Profiling analysieren. Oft wird man auch gezwungen sein, die gesamte Software-Architektur zu überdenken.

Wie es aussieht, kann der Weg auf die Tanzfläche ganz schon weit sein, wenn man HipHop tanzen will.

Tags: PHP, Facebook, HipHop, C++

Kommentare?

Kommentare bitte per E-Mail.