© saicle/Shutterstock.com
Wie Facebook PHP neu erfunden hat

Das Ende von PHP?


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?

High-Performance PHP with HipHop

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 No­SQL-­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.

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, ...

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