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

Neugierig geworden?

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