Kategorien
HipHop … warum hört man so wenig?
Ich habe schon einiges über die aktuelle Presse geschrieben. Alle sprechen über Microsoft, die Facebook API und ähnlichem. Keiner hat sich aber an den großen Hype der letzten Wochen herangetraut: Hip Hop. Aber woran liegt das?
Am Tag an dem Facebook angekündigt hat, dass sie einen Source-Code Transformer gebaut haben, der aus PHP Code C++ Code macht, konnte man kaum im Internet an dem Thema vorbei. Jeder hat darüber berichtet. Ich glaube wir waren die einzigen, die nur mal kurz einen Tweet zu dem Thema abgesetzt haben. Das lag aber eher daran, dass ich noch nicht ganz verstanden hatte zu dem Zeitpunkt, was Hip Hop eigentlich macht.
Ich will heute gar keinen Artikel über HipHop verfassen ist will nur mal eine Frage in die Runde werfen. Warum hört man nichts zu HipHop? Ich habe mal google trends angeworfen, um das Peak sichtbar zu machen.
Ich kann mir zwei gute Gründe vorstellen. Zum ersten ist es gar nicht so einfach HipHop zum laufen zu bringen. Wir haben zum Beispiel eine Ewigkeit gebraucht um es überhaupt zum Compilieren zu bringen. Ich habe aber noch gar nicht so viele Leute kennengelernt, die es überhaupt mal probiert haben.
Die zweite Möglichkeit ist: es bringt einfach nichts! Vielleicht sind ist der Benefit ja so gering, dass die Einschränkungen, die man sich auferlegt dies nicht aufwiegen. Was denkt ihr? Warum wird es gerade wieder leise um das Thema? Warum habt ihr es noch nicht installiert?
Wir haben zur Zeit einfach keine Zeit, aber wir haben geplant es mal für unser soziales Netzwerk zu testen. Wenn wir nur 30% der Webserver sparen könnten würde es sich schon lohnen, da mal 1-2 Tage Arbeit reinzustecken (aktuell sind es 24 Stück)
Also wir wissen jetzt schon, dass unsere Angebote nicht laufen werden.
Das Problem momentan ist wohl eher, dass Hip Hop momentan nur für sehr wenige Fälle einsetzbar ist, da es das php-Projekt gleich in einen eigenen Webserver packt. Daher sind mehrere Projekte (verschiedene Domains/Subdomains) nur mittels einer internen Umleitung möglich.
Der Vorteil ist bei reinen PHP-Anwendungen (vor allem bei hohem Traffik) durchaus vorhanden, jedoch liegt das bottleneck doch immernoch meist bei den Datenbankverbindungen. Und die bleiben bei Hip Hop bestehen.
Ich persönlich mag an PHP die Plattformunabhängigkeit. Auch wenn es ein paar spezielle Features nur für Windows oder nur für Linux gibt, ist es im Großen und Ganzen sehr leicht portierbar.
Zum teil entwickeln wir unter Windows und nutzen die Applikationen auf Linux. Mit Hip Hop beraubt man sich dieser Möglichkeit. Für jedes System muss man sich doch eine eigene Version compilieren.
Daneben hat PHP den simpelsten Deploymentworkflow (falls man den nutzen will). Ich ändere an einer Datei und nach einem Reload sehe ich die Änderung. Mit einem kompilierten Artefakt muss die Deploymentstrategie sehr wohl überlegt sein. Dies möchte nicht jeder investieren.
just my 2 cents
Ich vermute mal, das viele einfach einttäuscht sind, weil es nicht das bringt, was sie sich erhofft hatten. Nicht das, was Facebook gesagt hat, sondern wirklich, was sie sich erhofft hatten. Es ist für einen speziellen Anwendungsfall im High-Traffic-Bereich konzipiert worden und macht auch nur dort Sinn. Und das auch nur da, wo sich nicht dynamisch Dinge im Quelltext ändern, z.B. Datenbank Queries dynamisch gebildet werden o.ä. Ich glaube da wurde im Netz mehr Wind gemacht als eigentlich nötig war.
Nachtrag: Es ist im Prinzip so wie perl2exe, es gibt es, aber nicht jeder braucht es. 🙂
@Norbert
Mit HipHop kannst du doch weiter komplett in PHP entwickeln, d.h. du hast sowohl die „Plattformunabhängigkeit“ als auch simplen „Deploment-Workflow“. Erst im Release-Prozess wird dann das C++-Kompilat gebildet. Natürlich kann da etwas schief / kaputt gehen, aber wenn man sich an die HipHop-Vorgaben hält (keine eval und was es noch so gibt) dann sollte es schon klappen. Sicherlich wird der Deployment-Prozess sich verlangsamen, aber bei so einem großen Team wie bei Facebook macht das sicherlich Sinn, weil man eben so viele Serverkosten spart. Der QA und dem Test-Team kommen eben andere Verantwortung hinzu. Der Prozess ist eben ein ganz anderer.
Und warum wird jetzt kaum über HipHop berichtet? Weil es für 95% der Entwickler nicht interessant ist. Im Prinzip ist doch die ganze Sache erst reizvoll wenn man sehr viele Serverfarmen betreibt. Alt-Projekte können nicht einfach nach HipHop transformiert werden usw. Ich finde es interessant, dass es technisch geht PHP-Code in ein C++-Kompilat zu übersetzen, aber so etwas selber machen? Ich glaube das zahlt erstmal keiner wenn man damit einen halben bis einen Server einspart.
Das ganze kommt wohl wirklich auf den Anwendungsfall drauf an. Ich fände es ziemlich interessant wenn man die Möglichkeit hätte via HipHop eine PHP Extension bauen zu können. So könnte man bsp. Frameworkcode sind nativ ausführen lassen und könnte u.u. auf die Weise Overhead einsparen. Wobei natürlich die Frage ist wieviel man damit einspart.
Aus meiner Sicht ist HipHop (wie ja auch von den Entwicklern und vielen Artikeln beschrieben) nicht unbedingt für den Massenmarkt geeignet, sondern wirklich für sehr spezielle Projekte, bei denen es sich lohnt, die Zeit für die Konfiguration, Tests, etc. einzusetzen.
Ich bin auch der Meinung, dass das System auch viele Schwächen mitbringt (z.B. eine gewisse Abhängigkeit von den im Verhältnis zu PHP selbst wenigen Entwicklern, ihren Sponsoren und der allgemeinen Weiterentwicklung des Projektes) und in vielen Projekten ein opCode Cache die bessere Lösung ist.
Ich denke es liegt daran, dass es einfach noch nicht wirklich „fertig“ ist, oder? 😉 Warum soll ich mich mit etwas beschäftigen, dass hausintern entwickelt wurde und hausintern mit einer speziellen Anwendung gut funktioniert. Solange es noch nicht produktreif ist: also soweit dokumentiert und entwicklerfreundlich, dass es für die Massen geeignet ist, habe ich kein Interesse.
Momentan möchte ich „HipHop“ nicht einmal geschenkt haben.
Denke auch, dass das eher ein vorschneller Hype war. Zum einen die hochtrabende Ankündigung, die dann auf einmal wochenlang nicht weiter bedient, oder kommentiert wurde, zum anderen die halbgare Umsetzung des Compilers selbst. Nach der ersten Ankündigung, hab ich mir auch erstmal wesentlich mehr vom Konzept versprochen, geblieben ist einer weiterer, umständlicher PHP-Compiler.
Die Idee dahinter ist sogesehen nicht schlecht. Bringen tut es vielleicht Facebook was, da sie HipHop eben genau auf sich selbst zugeschnitten haben. Problem ist was auch schon in den Kommentaren angesprochen wurde: Es ist nicht fertig.
Wem die Datenbank zu langsam ist sollte isch vielleicht mal Gedanken um einen anderen Datenspeicher machen 😉 Das als Gegenargument für HipHop vu verwenden ist … naja, einfach falsch 🙂
HipHop for PHP ist nicht für kleine Seiten gedacht, sondern eher für große Websites und High Performance Websites, wo sowieso ein komplexeres Deployment verwendet wird.
Und damit sind wir eigentlich an der größten Hemmschwelle: jeder Entwickler würde gerne von jemand anderem ein Beispiel sehen. Die Unternehmen, die große Websites oder High Performance Websites haben, werden wohl erstmal den Teufel tuen, das auszuprobieren, da die Kosten dafür einfach zu hoch sind.
Es fehlt also irgendwie an Erfahrungsberichten und natürlich muss HipHop einfach einzurichten sein, denn solange es das nicht ist, hat es keine Chance. Ich warte ehrlich gesagt auch noch auf fertige Pakete für Ubuntu …
Ich habe HipHop auch mal angeschaut. Hatte aber auch das Problem das es relativ lange gedauert hat bis es richtig lief. Aber toll finde ich es nicht umbedingt.
@Flyingmana Ich habe mir HipHop bisher auch noch nicht so recht angesehen, wenn aber ein eigener Webserver dadurch erzeugt wird, gibt es trotzdem Möglichkeiten mehrere Vhosts sinnvoll auf einem System laufen zu lassen. Für lighttpd und apache gibt es mod_proxy mit dem man sowas auch sehr performant machen kann (d.h. ich bekomme alle HTTP-Requests da rein und verteile von da aus auf andere Webserver – je nach Vhost, URL usw..).
Ansonsten: Ich finde HipHop technisch schon interessant, für unsere Projekte dürfte sich das aber wohl kaum lohnen, ich denke die Einschränkungen bzw. der Aufwand beim zusätzlichen Testen, beim Deployment und bei der Administration lassen sich (zumindest wenn man nicht wirklich Facebook, studiVZ oder google heißt) nicht durch mehr Performance aufheben. Für die meisten eher statischen Seiten dürfte sich die Performance wesentlich effektiver steigern lassen wenn man sinnvoll Caches verwendet.
@Dennis Becker ich glaube gerade den größeren Unternehmen wäre das testen nicht zu teuer, wenn nur die Beispiele von Facebook im Management ankommen (x% der Server einsparen) wird man wohl zumindest zum Testen gezwungen. Nils hat damit ja offenbar schon Erfahrungen gemacht ;-).
Das Datenbanken häufig der limitierende Faktor sind der sich durch sowas nicht „beheben“ lässt dürfte hier jedem klar sein :-D.
Also ich höre schon seit über 20 Jahren Hip Hop und werde es auch weiter tun. Da kann sich Facebook auf den Kopf stellen… 😉
@Ralf: Mist, sowas wollte ich auch schreiben 😉
Jedenfalls: Ich persönlich hab damals im Facebook-Post keinen (eindeutigen) Projektlink ausmachen können und war zu faul zu suchen. Am Ende: So spannend find ich das Thema nun auch wieder nicht.
Ich verspreche mir von Hip Hop keinen großen Gewinn und habe es daher auch nicht getestet. Ich kann mir gut vorstellen, dass es auf stark frequentierten Seiten wie facebook eine Menge bringt. Aber bei einem durchschnittlichen Webprojekt liegen die Engpässe doch ganz woanders. Zumindest erscheint es mir vernünftiger Wege zu suchen um z.B. die HTTP Requests zu reduzieren, clientseitiges Caching zu optimieren oder die Möglichkeiten von Komprimierung auszuschöpfen.
Aber klasse das du das ansprichst, hab mich auch schon gefragt was aus dem großen Wurf geworden ist 😉
Grüße
Tobi
Inspiriert von Dennis wüde ich sagen, dass die großen Unternehmen sich wirklich momentan noch nicht trauen zu testen. Wir haben z.B. die Direktive, keine Beta-Software zu nutzen und an die wird sich strikt gehalten. Bis jetzt haben wir es auch nur „privat“ in einem kleinen team zum laufen bekommen.
Ich denke auch, dass HipHop die Wahl ist, wenn man noch das letzte bisschen Performance aus seiner Anwendung raus pressen will. Für die meisten Anwendungen ist es von der Aufwand-Nutzen-Rechnung deutlich sinnvoller am Code selber zu optimieren, da dort oft noch viel Potential ist. Weiterhin muss man bei HipHop die Einarbeitungszeit bedenken. Es ist ja nicht damit getan es zu kompilieren und auf einem Testserver zu installieren. Es geht darum wie integriert man es in den Workflow, Deployment, Test, etc. Das ist für große Projekte ein beträchtlicher Aufwand, der sich selten rechnet. Und für kleinere Projekte noch weniger.
Also sehe ich den Einsatz auch wirklich nur bei großen Anwendungen, die nur geringen Anpassungen unterworfen sind und die seeehr viele Benutzer haben.
Und der Hype entstand deshalb, weil es eine nette Sache in der Theorie ist und jemand eben einen Proof-of-Concept geliefert hat. Für die Praxis ist das eher irrelevant. Wenn eher noch für akademische Zwecke oder für die Entwickler der PHP-Sprache an sich.
So schlecht kann es nicht sein, schaue dir mal den Inhalt zu hiphop unter diesem Link an.
Es muss meiner Meinung nach leicht integrierbar für den Endanwender sein und out-of-the-box problemlos funktionieren. Dann wird es auch von der Masse angenommen, egal ob große oder kleine Anwendung.
Ich denke einfach mal „laut“, ob es realisierbar ist, weiß ich nicht: Wenn dieses Feature fester Bestandteil von PHP werden würde, entweder vom CLI-, CGI-Interpreter oder vom Apache-Modul, wäre das ein Schritt in die richtige Richtung. Sozusagen „dynamic compilation on the fly“ (Just-in-time compilation). Ähnlich wird es wohl auch von Python gemacht, allerdings wird hier nur Byte-Code erzeugt und ausgeführt. Und das dann alles per PHP konfigurierbar.
Wo ich gelesen habe, dass es per Apache usw. nicht funktioniert, habe ich aufgehört daran zu denken, es überhaupt einzusetzen.
Mir scheint es, als seien die meisten PHP-Entwickler in Sachen Deployment/Einfachheit sehr verwöhnt. Die erhöhte Komplexität durch HipHop erfordert nun mal ein ähnlich (umfangreiches) Deployment wie im J2EE-Bereich. Ist das so schlimm? Der einzige Unterschied besteht in der Auswahl an Tools, die zur Zeit für HipHop eben (noch) nicht existieren. Sobald Ant & Co. „HipHop-tauglich“ sind, wird das Deployment auch erträglich(er).
Außerdem: Was ist an einem alternativen Web-Server so schlimm? Es gibt ja auch lighttpd, Apache Tomcat oder JBoss.
Wieso muss PHP (oder zukünftig PHP++ ;-)) gleich immer ein LAMP sein?
Es kommt ganze einfach auf den Betrachtungswinkel an. 🙂
Das aktuelle Problem ist einfach noch, dass Hip-Hop die SPL nicht unterstützt.
Sonst bin ich von HipHop sehr begeistert, der interne Webserver liefert die Dokumente annähernd so schnell aus, wie ein Apache2 statische Dokumente ausliefert. (~20ms). Aber Performance ist ja bekanntlich nicht alles 🙂