Wie Facebook PHP neu erfunden hat

Das Ende von PHP?
Kommentare

Das PHP-Projekt hat trotz des immensen Erfolgs von PHP als Programmiersprache nicht unbedingt den besten Ruf. Man wird die Altlasten nicht los, dem Projekt fehle die Vision, überhaupt sei PHP eine gänzlich unsaubere Sprache, sagen Kritiker. Nun veröffentlicht Facebook mit HHVM nicht nur eine alternative Laufzeitumgebung, sondern legt mit Hack noch eine Weiterentwicklung der Programmiersprache drauf. Das Ende von PHP?

Facebook betreibt die vermutlich größte Website der Welt, und das ist mit Sicherheit nicht ganz einfach. Ein soziales Netzwerk basiert darauf, Beziehungen zwischen den Benutzern abzubilden und deren Kommunikation zu ermöglichen und ist daher nicht leicht zu skalieren. Anwendungen, bei denen die einzelnen Benutzer nichts miteinander zu tun haben, sind normalerweise deutlich einfacher skalierbar. Ein weiteres Problem ist die schier unglaubliche Masse an Nutzern, die Facebook hat. Pro Monat gibt es angeblich rund 1,2 Mrd. aktive Nutzer. Betrachtet man allein deren Loginvorgänge und verteilt diese gleichmäßig über die Zeit, dann kommt man auf etwa 9 000 Benutzer, die sich pro Sekunde am System neu anmelden. Die Seitenabrufe dieser Benutzer vor oder nach der Anmeldung haben wir dabei noch gar nicht betrachtet.

PHP-Anwendungen sind dank der Shared-Nothing-Architektur relativ einfach skalierbar: Man fügt einfach weitere Webserver hinzu. Meist wird mit einer zunehmenden Anzahl von Webservern die Datenquelle zum Flaschenhals. Das Geheimnis jeder performanten Datenquelle ist, alle Daten aus dem RAM auszuliefern. Ob man sich dazu darauf verlässt, dass die Datenbank alle Tabellen im RAM halten kann oder auf eine NoSQL-Technologie wie Redis oder Memcache setzt, ist zweitrangig. Laut einem Facebook-Ingenieur waren bei Facebook gegen Ende 2012 rund 800 Memcache-Server im Einsatz, die über 28 Terabyte Daten hielten.

Skalierungsprobleme

Wenn man die Datenquelle entsprechend skaliert hat, wird zumeist das Netzwerk zum Flaschenhals. So war es wohl auch bei Facebook. Man erzählt sich, dass man dort zur Lösung für den internen Netzwerkverkehr den TCP/IP-Stack neu implementiert hat, um die Netzwerklatenzen zu verringern. Man kann wohl sagen, dass die allermeisten Betreiber einer Webanwendung solche Probleme nie lösen müssen – entweder, weil sie noch immer mit der Skalierung der Datenquelle beschäftigt sind, oder weil sie die Netzwerklatenzen einfach akzeptieren.

Es zeigte sich vor einigen Jahren, dass der nächste Flaschenhals für Facebook die Ausführung des PHP-Codes war. Führt man ein PHP-Programm aus, wird dieses zunächst aus dem Quelltext in einen so genannten Bytecode übersetzt. Dieser ist gewissermaßen die Maschinensprache einer virtuellen Maschine. Dieses Konzept hat den Vorteil, dass die Ausführung eines PHP-Programms von der eingesetzten Hardware- und Prozessorarchitektur unabhängig ist. Im Prinzip erkauft man sich hier also durch eine zusätzliche Abstraktionsschicht (den Bytecode) Hardwareunabhängigkeit und bezahlt diese durch ein schlechteres Laufzeitverhalten im Vergleich zur Ausführung von nativer Maschinensprache direkt auf dem Zielsystem.

An dieser Stelle nun zu folgern, die Zend Engine wäre zu langsam, greift zu kurz. Eine interpretierte Sprache ist absichtlich „langsam“, da man beim Entwurf andere Eigenschaften wie die Portabilität höher priorisiert hat als die Ausführungsgeschwindigkeit. Nun läge es rein theoretisch auf der Hand, zur Beseitigung dieses Flaschenhalses die Abkehr von PHP und den Einsatz einer (echt) kompilierten Programmiersprache zu fordern. Dann könnte man zur Ausführungszeit nativ Maschinensprache ausführen, anstelle Bytecode zu interpretieren und könnte einen deutlichen Performancegewinn erwarten.

Millionen ade?

Nun trifft die Theorie aber in diesem Fall auf eine installierte Basis von mehreren Millionen Zeilen vorhandenem Programmcode. Genaue Zahlen werden nicht veröffentlicht, aber verschiedene Schätzungen gehen davon aus, dass die Codebasis von Facebook aus rund zehn bis dreißig Millionen Zeilen PHP-Code besteht. Eine Codebasis dieser Größe schreibt man nicht mal eben von heute auf morgen neu.

Was liegt also näher, als den ursprünglichen PHP-Quellcode automatisiert in eine andere Sprache zu übersetzen, statt die gesamte Anwendung neu zu schreiben? Die Programmierung und die Pflege könnten dann weiterhin in PHP erfolgen, zur Ausführungszeit käme dann aber nicht mehr die Zend Engine, also PHP, zum Einsatz, sondern eine alternative Laufzeitumgebung. In der Tat ist Facebook diesen Weg gegangen. Die Geschichte dieser Entwicklung beschreibt mein Kollege Sebastian Bergmann in seinem Artikel „HHVM“ in dieser Ausgabe. Der erste Schritt auf diesem Weg war HipHop, bei dem PHP in C++ übersetzt wurde. Der so entstandene Code wurde dann mit einem C++-Compiler in Maschinensprache übersetzt und dabei optimiert.

Neben der schnelleren Ausführung ergab sich für Facebook dadurch noch ein weiterer großer Vorteil, nämlich eine Ressourcenersparnis im mittleren zweistelligen Prozentbereich. Das bedeutet: Facebook benötigte mit HipHop deutlich weniger Server als mit PHP, um ihren Code auszuführen. Wenn man davon ausgeht, dass Facebook vermutlich eine sechsstellige Anzahl an Servern betreibt, dann zeigt sich hier ein gigantisches Einsparpotenzial, allein bei der Stromrechnung.

Für den Einsatz von HipHop hatte Facebook allerdings an anderen Stellen einen hohen Preis zu zahlen: Einige Vorteile einer Skriptsprache, nämlich die Möglichkeit, durch das Kopieren einiger weniger veränderter Quellcodedateien „mal schnell“ eine Applikation zu deployen, war nämlich verloren. Man musste beispielsweise eine rund 1,5 Gigabyte große Binärdatei auf die Zielsysteme bringen. Die Softwareentwickler aber waren es gewohnt, im Browser F5 zu drücken und damit den gerade geänderten Code direkt auszuführen.

Man schuf daher zusätzlich einen HipHop-Interpreter, um den Code nicht übersetzen zu müssen, sondern wie mit der Zend Engine interpretiert ausführen zu können. Dieser Ansatz erwies sich jedoch bald als Sackgasse, unter anderem, da es nicht gelang, sicherzustellen, dass sich die erstellte Software sowohl kompiliert als auch interpretiert exakt gleich verhielt.

[ header = Seite 2: Der Preis für die Geschwindigkeit ]

Alles hat seinen Preis

Ganz abgesehen vom erwähnten Deployment-Problem musste zunächst der PHP-Quellcode in C++ überführt und dann kompiliert werden, was auf einem einzigen Rechner selbst für eine kleinere Anwendung bereits mehrere Stunden dauerte. Für eine kleinere Firma hätte dies in der Praxis bedeutet, die durch den Einsatz von HipHop eingesparten Webserver als Compile-Farm einzusetzen. Ein weiteres Problem waren die Werkzeuge: Bekannte und beliebte PHP-Werkzeuge wie xdebug waren nicht mehr einsetzbar. Der Entwicklungsprozess hätte deutlich höhere Anforderungen an die Qualitätssicherung gestellt, da man erst nach mehreren Stunden Build-Zeit die Software hätte ausführen können. Es wäre daher umso wichtiger gewesen, Fehler bereits zur Entwicklungs- oder Übersetzungszeit aufzudecken. Letzten Endes hatte man durch den Einsatz von HipHop fast alle Vorteile, die der Einsatz einer Skriptsprache bietet, über Bord geworfen.

Der nächste Lösungsansatz hatte daher das Ziel, PHP-Code schneller und ressourcenschonender ausführen zu können, als dies die Zend Engine vermag, dabei aber die generellen Vorteile einer Skriptsprache nicht zu verlieren. Mit HHVM, der HipHop Virtual Machine, hat Facebook eine weitere alternative Laufzeitumgebung für PHP geschaffen, die zwischenzeitlich ebenfalls quelloffen zur Verfügung steht. Wie die Zend Engine übersetzt HHVM PHP-Quellcode zunächst in einen Bytecode; während dieser interpretiert wird, wird er allerdings in kleinen Schritten direkt in Maschinensprache übersetzt. Man spricht von Just-in-time-Übersetzung. Die Verarbeitung der ersten Anfrage ist dabei meist langsamer als bei der interpretierten Ausführung, die nachfolgenden Anfragen werden aber deutlich schneller verarbeitet.

Während es nach der Veröffentlichung von HipHop relativ still wurde, hat Facebook in den letzten Monaten viel Staub aufgewirbelt und sehr viel Werbung für HHVM gemacht. In zahlreichen Vorträgen, Blog-Posts und Veranstaltungen gelang es den HHVM-Entwicklern, nahezu alle bekannten PHP-Projekte zu einem gewissen Grad mit ins Boot zu holen. Ein erklärtes Ziel von Facebook ist es, eine hundertprozentige Kompatibilität zwischen HHVM und PHP herzustellen. Um diesem Ziel näherzukommen, begannen die HHVM-Entwickler damit, die Testsuites zahlreicher bekannter PHP-Projekte wie Zend Framework, Symfony, Drupal oder Doctrine mit HHVM auszuführen.

Die aufgetretenen Fehler und Probleme wurden schrittweise beseitigt, und obwohl man noch immer nicht bei einer hundertprozentigen Kompatibiliät angekommen ist, hat man doch ein viel wichtigeres Ziel erreicht: Nahezu alle größeren PHP-Projekte beschäftigen sich heute mit der HHVM und unterstützen Facebook teilweise darin, die Kompatibilität zu verbessern, indem sie zum Teil sogar Anpassungen an ihrer Software vornehmen.

Hundertprozentig

Eine hundertprozentige, absolute Kompatiblität zwischen HHVM und PHP kann und wird es meines Erachtens nie geben. Es wird immer subtile Unterschiede geben, etwa bei der internen Sortierung von Elementen. Als diese Zeilen geschrieben wurden, gab es beispielsweise einen Test aus der Drupal-Testuite, der unter HHVM fehlschlug, weil dort die Elemente einer Liste in einer anderen Reihenfolge zurückgeliefert wurden als von PHP.

Auf der anderen Seite fragt man sich, welche Rolle es spielt, ob sich HHVM zu 98, 99 oder 100 Prozent wie PHP verhält: Der kritische Erfolgsfaktor sind die großen und wichtigen PHP-Frameworks, -Anwendungen, wie MediaWiki, WordPress oder Bibliotheken wie Doctrine. Wenn diese ihre Software an HHVM anpassen, dann spielt es für den Endanwender keine Rolle mehr, welche Laufzeitumgebung hinter den Kulissen ihren Dienst verrichtet. Wohl aber wird sich der Anwender für die höhere Ausführungsgeschwindigkeit und den geringeren Ressourcenverbrauch entscheiden, wenn er die Wahl hat.

Für Code, der auf existierenden Projekten aufsetzt – sei es ein Plug-in für Drupal oder eine Website, die auf Symfony2 basiert – dürfte es technisch gesehen weitgehend egal sein, welche Laufzeitumgebung zum Einsatz kommt. Das bedeutet, dass möglicherweise eine große Anzahl von Anwendern relativ zeitnah zur HHVM wechseln, wenn die großen Frameworks sie unterstützen. Oftmals wird das noch nicht einmal eine bewusste Entscheidung sein. Oder wissen Sie, ob auf Ihrem Rechner eine Java Virtual Machine von Oracle oder einem anderen Hersteller läuft?

Das Problem, sich an subtile Unterschiede der Laufzeitumgebung anzupassen, ist nicht neu. Auch heute enthalten Frameworks Code, der von der eingesetzten PHP-Version und teilweise sogar -Konfiguration abhängt und bestimmte Probleme vermeidet, sie sich beim Einsatz einer bestimmten Version ergeben. Es dürfte also in der Praxis ausreichen, wenn sich HHVM „fast“ so verhält wie PHP – zumal sich ja auch PHP nicht immer so verhält wie PHP, was darin begründet ist, dass Linux-Distributionen oft ältere PHP-Versionen patchen. Auch durch PHP-Extensions kann das Verhalten von PHP verändert werden – die Runkit-Extension von Sara Golemon ist dafür vermutlich ein gutes Beispiel.

Wenn in der Praxis also nicht einmal für PHP selbst in allen Situationen ein einheitliches Verhalten garantiert ist, dies aber de facto für die meisten Anwender überhaupt keine Rolle spielt, dann steht einem Wechsel zu HHVM vermutlich nicht viel im Wege. Sicher ist, dass Facebook groß und bekannt genug ist, um ein Projekt wie HHVM zumindest erst einmal auf das Radar vieler Leute zu bekommen. Viele kleine Firmen und Projekte haben diese Möglichkeiten nicht. Oder kennen Sie Phalanger oder Roadsend?

[ header = Seite 3: Alles nur Kommerz? ]

Kommerzielle Interessen

Interessant ist, dass Facebook als Firma keinerlei kommerzielles Interesse an HHVM hat. Man betreibt die eigene Plattform darauf und will von daher vermutlich sicherstellen, dass diese nicht über die Zeit zu einer isolierten Insellösung wird. Man möchte ja schließlich auch auf dem Arbeitsmarkt neue Entwickler finden können, die ohne umfassende Einarbeitung produktiv werden.

Die Firma Zend trägt zwar in der Praxis relativ wenig zu PHP selbst bei, hat aber ein massives kommerzielles Interesse daran, da mit Werkzeugen und Dienstleistungen rund um PHP das Geld verdient wird. Facebook dagegen muss und möchte mit HHVM kein Geld verdienen. Ob dies nun (nur) ein Vorteil oder (auch) ein Nachteil ist, muss jeder für sich selbst bewerten und entscheiden.

HHVM ist kein echtes Open-Source-Projekt, denn die Facebook-Entwickler haben (zumindest noch) die vollständige Kontrolle. Ob sich dies ändern wird, hängt sicherlich auch davon ab, wie viele Anwender und potenzielle Kernentwickler auf den HHVM-Zug aufspringen werden. Aktuell ist es aber auf jeden Fall als Risiko zu werten, dass eine einzige Firma das HHVM-Projekt kontrolliert. Dennoch: Der Code ist quelloffen. Würde Facebook bei der Weiterentwicklung von HHVM eine Richtung einschlagen, mit der sich die Community der HHVM-Nutzer nicht identifizieren kann, dann könnte man sich jederzeit vom ursprünglichen Projekt abspalten und den Quellcode in einem weiteren Entwicklungszweig in eine andere Richtung weiterentwickeln. Mit OpenOffice und LibreOffice ist genau dies vor einiger Zeit in einem bekannten Open-Source-Projekt geschehen, und auch von MySQL gibt es mittlerweile viele verschiedene Varianten.

Man könnte nun argumentieren, dass es außerhalb von Facebook zu wenige Entwickler gibt, die HHVM so gut verstehen, dass sie die Wartung und Weiterentwicklung federführend in die Hand nehmen könnten. Das ist aber auf der anderen Seite im PHP-Projekt nicht anders. Hier gibt es vielleicht zwei Dutzend Personen mit umfassenden Kenntnissen über die Zend Engine.

Traditionell werden viele PHP-Kernentwickler von Firmen bezahlt, um an PHP zu arbeiten. Für die Firmen rechnet sich das, weil man eine quelloffene Plattform ohne Lizenzgebühren nutzen und deren Weiterentwicklung in einem gewissen Rahmen beeinflussen kann. Ob dies nun in Form von Änderungen erfolgt, die in das offizielle PHP-Projekt zurückfließen, oder man wie im Fall von Yahoo intern eine stark angepasste PHP-Variante pflegt, spielt an dieser Stelle keine Rolle. Ein gesundes Ökosystem aus Kernentwicklern, Contributors und Anwendern entsteht nicht von heute auf morgen, ist aber eine wichtige Voraussetzung für den langfristigen Bestand eines Open-Source-Projekts. Und auch wenn viele Open-Source-Projekte im Ruf stehen, Freizeitprojekte zu sein, braucht man auf Dauer Firmen, die das Projekt direkt oder indirekt mit Geld oder Leistung unterstützen.

Das PHP-Projekt hat nicht unbedingt den besten Ruf. Die Entscheidungswege sind traditionell eher intransparent und für Außenstehende schwer nachvollziehbar, auch wenn sich dieser Zustand durch das RFC-Wesen und die öffentlichen Abstimmungen schon deutlich gebessert hat. Oft wird auch kritisiert, dem PHP-Projekt fehle das „Leadership“ und eine klare Vision für den Weg in die Zukunft.

Das HHVM-Projekt wird zurzeit ausschließlich von Facebook gesteuert und gefördert. Das mag auf Dauer kein erstrebenswerter Zustand sein, ermöglicht es aber zumindest kurzfristig, gemeinsam auf ein klares Ziel hinzuarbeiten. Inwieweit es Facebook gelingen wird, aus dem HHVM-Projekt ein echtes Open-Source-Projekt zu machen, bleibt abzuwarten. Das PHP-Projekt hat es trotz aller Unkenrufe geschafft, eine der weltweit meistverwendeten Programmiersprachen zu werden, die auf einem Großteil aller Server im Internet läuft.

Aktuell merkt man dem HHVM-Projekt noch relativ stark an, dass hier bei Facebook intern verwendete Software für die Veröffentlichung aufbereitet wurde. Bis zur Version 3.0 brachte HHVM beispielsweise noch einen von Facebook selbst entwickelten Webserver mit. Dieser ist Multi-Threaded und soll so interessante Dinge beherrschen wie die Übergabe einer bestehenden TCP/IP-Verbindung an eine neue Instanz, sodass Softwareupdates jederzeit im laufenden Betrieb eingespielt werden können. Es war jedoch bereits vorab von Facebook angekündigt worden, dass dieser Webserver aus HHVM entfernt werden wird.

Stattdessen wird die Anbindung von HHVM an gängige Webserver wie nginx per FastCGI-Protokoll empfohlen. Der Einsatz von Apache – zumindest der Einsatz von mod_php – ist ja heutzutage ohnehin verpönt, wie mein Kollege Arne Blankerts in dem Artikel „Goodbye LAMP Stack“ in Ausgabe 4.14 des PHP Magazins deutlich macht.

Windows wird von HHVM aktuell nicht unterstützt, was gewisse Erinnerungen an frühere Jahre der PHP-Entwicklung hervorruft.

Windows außen vor – wieder einmal

Damals war PHP auf Windows zwar im Großen und Ganzen irgendwie lauffähig, Windows wurde aber nicht offiziell unterstützt. Unter den PHP-Kernentwicklern waren schlichtweg zu wenig Windows-Benutzer, also war niemand bereit, die notwendige Arbeitszeit zu investieren, um PHP auch unter Windows zu einem First Class Citizen zu machen.

Die Firma Microsoft selbst begann vor einigen Jahren, sich für eine verbesserte Windows-Unterstützung von PHP einzusetzen, mit dem Ergebnis, dass PHP seit der Version 5.3 sowohl Unix/Linux- als auch Windows-Betriebssysteme nahezu gleichwertig unterstützt.

Nun mag man von Windows halten, was man will: Es ist Realität, dass zahlreiche Firmen eine Microsoft-basierte Infrastruktur haben und ungern Unix- oder Linux-Server einsetzen. Dies geschieht weniger aus religiösen Gründen, sondern schlichtweg deshalb, weil die Administratoren im Haus zumeist zu wenig Linux-Kenntnisse haben, um die Systeme zuverlässig warten zu können.

Während man sich als Windows-Anwender heute auf die PHP-Unterstützung von Microsoft verlassen kann, steht man bei HHVM erst einmal im Regen. Nicht zu vergessen ist auch, dass sehr viele PHP-Entwickler unter Windows arbeiten, auch wenn der Code letzten Endes auf Linux-Servern ausgeführt wird. Virtuelle Maschinen machen die Koexistenz von Windows und Linux auf einem Arbeitsplatzrechner zwar relativ einfach, dennoch ist die Hürde für einen Wechsel für viele relativ hoch.

Es bleibt abzuwarten, ob und wann HHVM auch Windows unterstützt. Für Facebook dürfte dies keine allzu hohe Priorität haben. Vielleicht liegt es auch (erneut) an Microsoft, dafür zu sorgen, dass eine PHP-Laufzeitumgebung (in diesem Fall HHVM) auch Windows zuverlässig unterstützt.

[ header = Seite 4: Pro und Contra, Fazit ]

Regen und Sonnenschein

Ein nicht zu unterschätzender Nachteil für viele PHP-Anwender ist, dass sämtliche vorhandenen PECL-Erweiterungen nicht mit HHVM funktionieren. Zwar wurden die wichtigsten Erweiterungen für HHVM neu entwickelt, aber wer auf eine eher exotische oder gar selbst entwickelte PECL-Extension angewiesen ist, hat erst einmal das Nachsehen.

Auf der anderen Seite gibt es Hoffnung: Während man PECL-Extensions in C entwickeln muss(te), kann man Erweiterungen für HHVM in PHP schreiben. Da der gesamte Code ohnehin übersetzt wird, spielt es plötzlich keine Rolle mehr, in welcher Programmiersprache eine „Erweiterung“ entwickelt wurde. Wer auf externe Bibliotheken zugreifen will, dem steht mit der HNI (HHVM Native Interface) ein API zur Verfügung, mit dem dies direkt aus PHP heraus möglich ist.

Dies eröffnet neue Möglichkeiten: Wo man bisher in PHP gezwungen war, Erweiterungen in C zu schreiben, um bestimmte performancekritische Aufgaben zu erledigen, kann man solchen Code für die HHVM direkt in PHP schreiben. Eine echte Erweiterung wird nur noch dann gebraucht, wenn man tatsächlich auf externe Bibliotheken zugreifen muss. Beim Einsatz des klassischen, interpretierten PHP wurde für manche Anwender der Overhead, den Frameworks oder bestimmte Bibliotheken mit sich brachten, zu einem ernsthaften Problem. Die HHVM könnte hier Abhilfe schaffen. Dies könnte auf längere Sicht allerdings auch dazu führen, dass immer weniger leichtgewichtige PHP-Anwendungen geschrieben werden. In der Tat könnte wahr werden, was für viele ein Albtraum ist: PHP könnte noch viel mehr wie Java werden, und die HHVM wäre der Beschleuniger dieses Prozesses.

Aber auch das PHP-Projekt hat bisher dem Geschehen nicht tatenlos zugesehen. Bald nachdem Facebook HipHop veröffentlichte, wurde mit der Version 5.4 die Performance von PHP deutlich verbessert. Ob nun die Motivation dafür tatsächlich war, dass man den beeindruckenden Benchmark-Ergebnissen von HipHop etwas entgegensetzen wollte, sei dahingestellt. Genauso kann man sich fragen, ob es von ungefähr kommt, dass auf PHP Internals, der Mailing-Liste der PHP-Kernentwickler, nun plötzlich von PHP 7 die Rede ist. Nach dem großen Debakel mit PHP 6, das Unicode-basiert sein sollte und dessen Entwicklung aus verschiedenen Gründen wieder eingestellt wurde, konnte man sich im PHP-Projekt lange Zeit nicht einigen, in welche Richtung die Entwicklung nun eigentlich weitergehen soll.

Die Crux dabei ist die Rückwärtskompatibilität. Sie ist Fluch und Segen zugleich. Man fürchtet, durch Brüche in der Rückwärtskompatibilität viele Anwender zu verprellen, die doch nur Drupal, WordPress oder phpMyAdmin ausführen wollen, und möglicherweise nicht genug technisches Hintergrundwissen haben, um eine Migration sauber und professionell durchzuführen. Die Konsequenz davon ist, dass keine Aktualisierung auf eine neuere PHP-Version erfolgt, weil man die damit verbundenen Probleme meiden will. Die quälend langsame Adoption von PHP 5 ist ein sehr gutes Beispiel dafür.

Der Einsatz mancher Altlasten wie register_globals oder magic_quotes verbietet sich aus heutiger Sicht allein aus Sicherheitsüberlegungen heraus für jedes Programm, das über ein einfaches Skript hinausgeht. Dennoch hat man diese Features irgendwann in der Vergangenheit für sinnvoll erachtet, und es hat bis zur PHP-Version 5.4 gedauert, bis man sie schließlich wieder aus PHP entfernen konnte.

Mit PHP 7 als nächster Major-Version wird man vermutlich die Gelegenheit nutzen und einige Brüche in der Rückwärtskompatibilität einführen. Bevor PHP 7 erscheinen kann, ist allerdings erst einmal mit einer Entwicklungszeit von ein bis zwei Jahren zu rechnen. Wenn in dieser Zeit keine signifikanten neuen Features in den PHP-5-Zweig kommen und sich auch die Performance nicht merklich weiter bessert, dann werden vermutlich mehr und mehr Anwender in Richtung HHVM schielen. Und wenn man sich überlegt, dass man nach dem Erscheinen von PHP 7 seine Anwendungen ohnehin kritisch überprüfen und hier und da anpassen muss, dann könnte man dies eigentlich auch schon heute beginnen und seine Anwendung an die HHVM anpassen.

Es bleibt also spannend. In jedem Fall werden am Ende alle PHP-Anwender von HHVM profitieren – entweder direkt, in dem sie HHVM statt PHP nutzen, oder indirekt, indem das PHP-Projekt mit neuen Ideen und weiteren Verbesserungen aufwartet. Konkurrenz belebt eben das Geschäft.

HHVM ist als Ausführungsumgebung eine interessante Alternative zu PHP. Facebook ist jedoch noch einen weiteren Schritt gegangen und hat mit Hack eine auf PHP basierende Programmiersprache geschaffen. Hack zeichnet sich ganz abgesehen vom fragwürdigen Namen durch ein strikteres Typkonzept als PHP aus, das aber rein optional ist. Zusätzlich gibt es gegenüber PHP einige neue Konstrukte, die gerade das objektorientierte Programmieren deutlich erleichtern können.

Der Vorteil eines strikten Typkonzepts ist, dass mehr Programmierfehler bereits zur Entwicklungszeit aufgedeckt werden können und sich nicht wie in PHP als Laufzeitfehler manifestieren. Der Aufruf $a->method() beispielsweise ruft eine Methode auf dem Objekt auf, das durch die Variable $a referenziert wird. Enthält $a aber keine Objektreferenz, führt dies zu einem Laufzeitfehler. Zwar kann man in PHP für Objekte einen Type Hint verwenden, aber diesen zu verletzen, führt ebenfalls zu einem Laufzeitfehler.

Wer mehrere Millionen Zeilen Code warten und erweitern muss, für den bietet Hack interessante Möglichkeiten, Fehler deutlich früher zu erkennen, auch ohne dass man umfassende Unit Tests schreibt. Letztlich ist das Testen in kleinem Scope gerade in PHP deshalb so wichtig, weil man damit die eingeschränkten Möglichkeiten der statischen Analyse ausgleicht. Mit Hack kann man bestimmte Fehlerklassen einfacher, schneller und kostengünstiger aufdecken als mit PHP.

Fazit

Ob nun PHP oder HHVM das Rennen macht, lässt sich heute noch nicht absehen. Ich vermute, die Entscheidung wird letztlich von großen Anwendungen wie Magento, SugarCRM oder OXID eShop gefällt werden. Sie sind nicht gerade für ihre hervorragende Performance bekannt. Von daher dürfte der Anreiz groß sein, solche Anwendungen auf HHVM zu betreiben. Dafür müssen natürlich auch die Hoster und Cloud-Anbieter mit ins Boot. Auch für sie wird es interessant sein, PHP-Applikationen unter Einsatz von weniger Systemressourcen zu hosten, beziehungsweise den Kunden mehr Performance bieten zu können. Wenn genug Anwendungen unter HHVM laufen und dort deutlich performanter sind als unter PHP, dann werden sich die großen Anwender nach und nach für HHVM als Laufzeitumgebung entscheiden.

Die ersten Schritte kann man heute schon relativ risikolos gehen, denn man muss ja nicht gleich vollständig zu HHVM wechseln. Dank FastCGI können auf einem Server PHP und HHVM nebeneinander laufen und man kann für jeden eingehenden Request entscheiden, welche Ausführungsumgebung für dessen Abarbeitung verwendet wird. Dieser Ansatz bietet interessante Möglichkeiten, selektiv von den Vorteilen der HHVM zu profitieren.

Facebook hat uns mit HHVM und Hack einen möglichen Weg in die Zukunft aufgezeigt. Nun bleibt abzuwarten, ob das PHP-Projekt mit PHP 7 eine ebenso vielversprechende Alternative bieten kann.

Stefan PriebschStefan Priebsch ist IT-Consultant und Mitgründer von The PHP Consulting Company (thePHP.cc). Seine Spezialdisziplinen sind objektorientierte Programmierung und Softwarearchitektur. Als Vater von dreijährigen Zwillingen ist er zudem ein ausgewiesener Experte für Skalierungsfragen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -