Het grote HipHop ervaringen topic

[DexterDee]

Facebook HipHop-PHP

Dit topic is bedoeld om ervaringen uit te wisselen over de installatie en het gebruik van Facebook's HipHop bij het coderen en uitvoeren van PHP code. Vragen en problemen met het compileren en draaien van HipHop kunnen hier gesteld worden. Tevens kan er gediscussieerd worden over de zin, onzin en oorzaken achter het gedrag dat deze crosscompiler veroorzaakt. Tot slot is het interessant om over specifieke performance winst of verlies te discussiëren bij bepaalde code implementaties.

Wat is HipHop?

HipHop maakt van dynamische PHP code geoptimaliseerde maar statische C++ code en compileert het via de GNU C++-compiler G++. Hierdoor zal de algemene performance van de code toenemen volgens Facebook.
Er wordt in diverse media gemeld dat Facebook een "eigen" snelle variant van PHP vrijgeeft, maar dit is niet geheel correct. Hoewel Facebook ook een interpreter aanbiedt die rechtstreeks PHP code kan parsen en uitvoeren, is dit niet het hoofddoel van dit project. Deze interpreter is gemaakt voor het debuggen van PHP code en heeft tevens als doel om bugs op te sporen die de crosscompiler onverhoopt introduceert.

Hoe werkt HipHop?

HipHop bestaat na een succesvolle build onder andere uit twee executables:

• HPHP
  de commandline tool om een of meerdere PHP bestanden te porten naar C++ en deze als één native binary te compilen
• HPHPI
  de commandline tool om PHP bestanden interpreted (regel voor regel) uit te voeren, waarbij debugging mogelijk is en waarbij de werking van de portering van de code getest kan worden

De HPHP commandline tool kent een groot aantal parameters. Door alleen een PHP bestand mee te geven zal deze tool het PHP bestand porten naar C++, compilen en linken naar een executable. De executable wordt in een tijdelijk pad gezet (systeemafhankelijk, meestal /tmp) en uitgevoerd. Direct na de lancering van de executable wordt het tijdelijke pad inclusief executable verwijderd.

Om te voorkomen dat de executable verwijderd wordt, kan de vlag --keep-tempdir=1 meegegeven worden. De output directory kan gemanipuleerd worden met de vlag --output-dir.

Een executable is allemaal leuk en aardig, maar verreweg de meestgebruikte functie van PHP is het genereren van webpagina's. Door de executable op te starten van de commandline, zal deze als CLI uitgevoerd worden. Omdat Apache integratie vooralsnog ontbreekt (er zijn plannen voor een FastCGI implementatie) zal de functionaliteit van de code op een andere manier naar de browser toe moeten. De Facebook programmeurs hebben dit opgelost door een multithreaded webserver mee te compilen in de executable. Deze kan getriggered worden met de parameter -m server

Standaard probeert de ingebouwde webserver op poort 80 actief te worden. Vaak is dit niet mogelijk omdat er al een apache instantie draait of omdat de gebruiker geen root is en geen poorten onder de 1024 open mag zetten. In dat geval kan een aparte poort opgegeven worden met parameter -p 8080 voor poort 8080. Tot slot is het mogelijk om de executable in de achtergrond te laden door in de parameter -m het woord server door daemon te vervangen (-m daemon). Verdere informatie is te vinden door hphp --help te gebruiken of op de officiele wiki te kijken

Als een executable als webserver gestart wordt, komt er standaard een aparte administration server actief op poort 8088. Hier kunnen allerlei commando's gegeven worden om statistieken aan of uit te zetten en op te vragen.

Eigenaardigheden van HipHop

Als eerste valt de compile performance op als de tool voor het eerst gebruikt wordt. Bij het uitvoeren van HPHP op een simpel 'Hello World!' PHP bestand is de tool minimaal al een minuut zoet. Ik heb persoonlijk nog geen hands-on ervaring met het compilen van een grote codebase

Als tweede valt de gecompileerde binary op. Het simpele 'Hello World' voorbeeld levert een binary op van maar liefst 29 megabyte.

Wat ook opvalt is dat in simpele voorbeelden al duidelijk blijkt dat de performance negatief afsteekt tegen het regulier draaien van een PHP script. Een voorbeeld hiervan kun je hier vinden.

Tot slot een waarschuwing voor mensen die een 32-bit linux systeem hebben. De huidige HipHop sourcecode is nog niet compatible met 32-bit en kan niet gecompiled worden op deze systemen. Een 64-bit systeem is benodigd om HipHop succesvol te builden.

Installatie van HipHop

Uitgaande van een Red Hat Enterprise Linux (of Centos) server versie 5.4 is hier de lijst van benodigdheden, aangevuld met hoe en waar ik de diverse packages heb gevonden:

• cmake 2.6.4 is the minimum version
  yum install cmake (standaard repository)
• g++/gcc 4.1 is the minimum version
  yum install gcc-c++ (standaard repository)
• Boost 1.37 is the minimum version
  Ik heb versie 1.38 van source gecompiled: http://sourceforge.net/pr...st_1_38_0.tar.gz/download
• flex
  De versie in de standaard repository is te oud. Ik heb 2.5.35 van source gecompiled: http://www.sfr-fresh.com/unix/misc/flex-2.5.35.tar.gz
• bison
  yum install bison (standaard repository)
• re2c 0.13.0 is the minimum version
  yum install re2c (rpmforge repository)
• libmysql
  yum install mysql mysql-devel (standaard repository)
• libxml2
  yum install libxml2 libxml2-devel (standaard repository)
• libmcrypt
  yum install libmcrypt libmcrypt-devel (standaard repository)
• libicu 4.2 is the minimum version
  Ik heb versie 4.2.1 van source gecompiled: http://download.icu-proje...4.2.1/icu4c-4_2_1-src.tgz
• openssl
  yum install openssl openssl-devel (standaard repository)
• binutils and binutils-dev
  yum install binutils binutils-devel (standaard repository)
• libcap
  yum install libpcap libpcap-devel (standaard repository)
• gd
  yum install gd gd-devel (standaard repository)
• zlib
  yum install zlib zlib-devel (standaard repository)
• tbb Intel’s Thread Building Blocks
  Compiled versie gedownload van: http://www.threadingbuild.../2.2/tbb22_004oss_lin.tgz
• libmbfl
  Gecompiled van git clone git://github.com/scottmac/libmbfl.git
• Oniguruma
  Versie 5.9.2 gecompiled van source: http://www.geocities.jp/k...archive/onig-5.9.2.tar.gz
• libpcre3
  yum install pcre pcre-devel (standaard repository)
• libexpat
  yum install libexpat libexpat-devel (standaard repository)

De installatie instructies staan hier:
http://wiki.github.com/fa...p/building-and-installing

In de installatie instructies staat het git commando git submodule. Het blijkt dat de versie van git uit de standaard repository te oud is en dit commando niet snapt. Om dit commando te kunnen uitvoeren is een update van git nodig. Ik heb dit bereikt door de nieuwste versie van git te compilen. Hier is de link:
http://kernel.org/pub/software/scm/git/git-1.7.0.tar.bz2

Nog te onderzoeken

HipHop is nog erg nieuw en er is behalve bij de Facebook ontwikkelaars nog niet veel bekend over de sterke en zwakke gebieden van deze tool.
De volgende items zijn mogelijk interessant om te onderzoeken:

• Testen van de performance winst of verlies van veelgebruikte native PHP commando's
• Performance winst of verlies bij diverse design patterns en implementaties
• Testen van veelgebruikte extensies
• Performance en stress test van de ingebouwde webserver, vergelijken met apache+php
• Onderzoeken van portability van de executable over meerdere distros
• En meer...

De toekomst

Het is inmiddels bekend dat Facebook HipHop geschikt wil maken voor PHP 5.3. Op dit moment is HipHop uitsluitend geschikt om PHP 5.2 code om te zetten.
Wat ook is aangekondigd is een FastCGI interface als compile optie in plaats van de ingebouwde webserver. Op die manier kunnen de gecompilede binaries direct door apache aangesproken worden.
Persoonlijk zou ik een CLI only compile optie graag tegemoet zien, waardoor de grootte van de binary hopelijk drastisch afneemt en minder bloated wordt.

Tot slot...

Bij deze dus een uitnodiging om aan de slag te gaan met HipHop en in dit topic uitgebreid je bevindingen te rapporteren. Mocht ik nog dingen in de TS vergeten zijn, slinger dan even een DM mijn kant uit, dan zetten we het erbij.

[Cartman!]

Mooie TS! We hebben er hier al duidelijk naar gekeken maar het is nog niet inzetbaar bij de gemiddelde hostingpartij. Ik maak me echter erg zorgen over het hello world voorbeeld van 29MB, wat zit er dan allemaal in dat bestand extra verstopt

[YopY]

Cartman! schreef op woensdag 24 februari 2010 @ 11:24:
Mooie TS! We hebben er hier al duidelijk naar gekeken maar het is nog niet inzetbaar bij de gemiddelde hostingpartij. Ik maak me echter erg zorgen over het hello world voorbeeld van 29MB, wat zit er dan allemaal in dat bestand extra verstopt

Bij de gemiddelde hostingpartij zal gewoon PHP ook wel voldoen, lijkt me. Als je echt zoveel gebruikers hebt dat je dit soort dingen toe moet passen, zul je waarschijnlijk ook al dedicated hosting krijgen.

En ik denk dat de gehele PHP executables in de binary meegenomen wordt - het is immers een stand-alone programma, en daar het nog een vroege versie lijkt te zijn die gericht is op grote omgevingen, lijkt het me logisch dat ze alle PHP functies mee gaan nemen in de gecompileerde binary.

Maar een grote binary is Niet Erg, imho, niet als je 70% performancewinst heb. Daar komt bij dat grote PHP programma's ook wel zo groot (of zelfs groter) kunnen zijn.

[Kalentum]

YopY schreef op woensdag 24 februari 2010 @ 11:55:
[...]

En ik denk dat de gehele PHP executables in de binary meegenomen wordt - het is immers een stand-alone programma, en daar het nog een vroege versie lijkt te zijn die gericht is op grote omgevingen, lijkt het me logisch dat ze alle PHP functies mee gaan nemen in de gecompileerde binary.

Denk ik ook: ik heb hier een custom gecompileerde PHP binary en die is 20 Mb. Daar zitten dus alle extensies ingebakken. De binaries die ik van Debian gebruik zijn rond de 5 Mb.

[hostname]

Ik heb het ook even geprobeerd, maar aangezien alle includes tijdens het compileren geresolved worden, moet die in 99% van de gevallen gaan aanpassen. Verder mist PDO nog, dus ik heb het nog niet op mijn eigen codebase kunnen proberen.

Voor de debian gebruikers: in Squeeze/testing heb je deze pakketten nodig:

code:

sudo aptitude install cmake g++ libboost-dev flex bison re2c libxml2 libmcrypt4 libmysql++3 libgd2-xpm zlib1g libicu42 libtbb2 libonig2 build-essential libboost-filesystem-dev libboost-system-dev libboost-program-options-dev libmysql++-dev libpcre3-dev libgd2-xpm-dev libxml2-dev libmcrypt-dev libicu-dev libtbb-dev libssl-dev binutils-dev libcap-dev libonig-dev php5-dev

In Lenny is o.a. de boost versie te oud volgens de requirements. Nog niet geprobeerd of het via backports mogelijk is.

[DexterDee]

hostname schreef op woensdag 24 februari 2010 @ 12:23:
Ik heb het ook even geprobeerd, maar aangezien alle includes tijdens het compileren geresolved worden, moet die in 99% van de gevallen gaan aanpassen. Verder mist PDO nog, dus ik heb het nog niet op mijn eigen codebase kunnen proberen.

HipHop is wel zo slim dat hij includes als deze:
include_once $MY_ROOT.'/path/file.php';
kan resolven met behulp van een configuratie bestand waar deze mappings in staan. Op die manier voorkom je dat je de code zelf moet aanpassen

Wat betreft de binary size, er zit geen PHP executable in of gecompileerde code van de PHP interpreter zelf. Wel zijn alle extensies meegecompiled, alsmede de hulpbibliotheken van HipHop zelf om chocola te maken van de naar C++ omgezette PHP code. Als laatste zit de multi-threaded webserver er ook helemaal in. Als het goed is heeft de binary geen dependencies met PHP specifieke libraries.

[hostname]

Qua includes mis ik eigenlijk vooral nog autoload ondersteuning.

[StM]

Je hebt geen autoloader meer nodig als het goed is aangezien alle classes en functies tijdens het compileren gedefineerd worden Context afhankelijk functies defineren is daardoor echter niet mogelijk.

[hostname]

Site.to.Make schreef op woensdag 24 februari 2010 @ 21:57:
Je hebt geen autoloader meer nodig als het goed is aangezien alle classes en functies tijdens het compileren gedefineerd worden Context afhankelijk functies defineren is daardoor echter niet mogelijk.

Ja, maar het zou mooi zijn als de compiler autoload snapte, zodat je niet die code overhoop hoeft te gooien

[DexterDee]

hostname schreef op woensdag 24 februari 2010 @ 22:54:
[...]

Ja, maar het zou mooi zijn als de compiler autoload snapte, zodat je niet die code overhoop hoeft te gooien

Ik denk dat de magic method __autoload haaks staat op de filosofie van HipHop om de performance te verbeteren. Je kiest voor autoloading omdat het gemakkelijker is, niet omdat je daar snelheidswinst uit haalt. Magic methods staan dan ook hoog op het lijstje om gerefactored te worden als je de performance wil verbeteren van je PHP scripts.

[wackmaniac]

Even een vraagje tussendoor; weet iemand of het mogelijk is om een deel van je codebase met HipHop te behandelen en dan via "old-skool" php ermee te communiceren? Zou namelijk een uitkomst zijn om bv Zend-framework via HipHop te compileren en dan je eigen projectimplementatie met deze code te laten communiceren. Helemaal als je op een server meerdere projecten hebt draaien op een enkele instantie van een framework. Mijn verstand zegt dat het niet gaat werken, maar voor de zekerheid toch maar ff navragen

[ Voor 24% gewijzigd door wackmaniac op 25-02-2010 10:50 . Reden: toevoeging ]

[Voutloos]

Voor een dergelijke werkwijze moet je denk ik eerder naar iets als PHC kijken, die maakt tenminste niet 1 grote niet herbruikbare executable.

[DexterDee]

wackmaniac schreef op donderdag 25 februari 2010 @ 10:47:
Even een vraagje tussendoor; weet iemand of het mogelijk is om een deel van je codebase met HipHop te behandelen en dan via "old-skool" php ermee te communiceren?

Met Roadsend (een alternatieve PHP compiler) kun je libraries compilen en deze gebruiken in je reguliere PHP code:
http://www.roadsend.com

Het is een interessant project, maar ik ben vooral geinteresseerd in hun nieuwe project, Roadsend Raven. Dit is naast een native compiler voor PHP ook nog een JIT compiler en werkt op basis van LLVM. Helaas is het nog in een alpha fase en niet echt bruikbaar voor serieuze code.

[Phoib]

Aangezien de openingspost erg goed is, wil ik graag verder gaan in deze discussie, en even kort over mijn ervaringen met Hiphop vertellen, alvorens zelf een vraag te deponeren.

Ik werk sinds een paar maanden voor een middelklein software bedrijf, dat na 8 jaar zo'n 27 Mb aan pure PHP code heeft gegenereerd. Heeft in 2008 een jaar geduurd om van PHP4 naar PHP5 over te gaan, en heeft alsnog een berg legacy code die, om het zacht uit te drukken, even snel is als een platgewalste slak.
Omdat die code zo groot is, en ik de enige in het bedrijf ben die in een andere taal dan PHP kan programmeren, besloot ik Hiphop uit te proberen.

Het geinstalleerd krijgen van Hiphop, via een Poolse pagina, was vrij lastig. Het heeft me een paar keer opnieuw proberen opgeleverd, en af en toe "raakt" Hiphop z'n custom libevent kwijt, waardoor opnieuw compileren eigenlijk de enige oplossing is. De handleiding is soms spartaans, en de foutmeldingen wordt je ook niet altijd wijzer van. Ook worden niet alle functies gebruikt (gregoriantojd kent hij niet, , en eval wordt maar een keer of 20 gebruikt ofzo ) en er valt aan veel zaken te merken dat Hiphop nog in ontwikkeling is, en moet je niet verbaasd zijn als je 25+ Mb aan PHP code voor 2 uur aan het compileren is, zonder progress ertussen. (ideaal overigens om de vrijdagmiddag borrel mee te starten)

Maar de aanhouder wint. Waar normaal de indexpagina er 107 miliseconden over doet, doet een gecompilde Hiphop er 5 miliseconden over. (Gemiddeld na 30 metingen per stuk). Andere pagina's laden ook ongelovelijk snel, en de performance is veel beter dan ik had durven dromen.

Zeker, voor een Hello World is HipHop al even bezig, en losse functies vergelijken zal je ook niet veel wijzer van worden, maar allemachtig, wat is het snel bij grote PHP projecten!


En dan nu mijn vraag... Hiphop wordt verspreid onder de CC-BY-SA license, die hier wordt vermeld: http://creativecommons.org/licenses/by-sa/3.0/deed.nl Nu ben ik geen advocaat of rechterlijk geschoold, maar het werk moet onder dezelfde licentie gedeeld worden. Betekent dit ook dat alle code, gecompileerd door HPHP, ook onder die licentie verspreid moet worden?

[armageddon_2k1]

Phoib schreef op zaterdag 28 januari 2012 @ 01:01:.
Omdat die code zo groot is, en ik de enige in het bedrijf ben die in een andere taal dan PHP kan programmeren, besloot ik Hiphop uit te proberen.

Wait what?? Jij bent dan straks de enige in het bedrijf die dus eventueel met de omgezette code zo kunnen werken en de quirks begrijpt van hem omzetten? Als er één manier is om je veel problemen op de hals te halen is het wel als enige verantwoordelijk te zijn voor een enorme codebase.

[ZpAz]

Ik dacht dat dat zorgde voor een stevigere onderhandelingspositie bij het onderhandelen voor een loonsverhoging.

[NMe]

Sowieso vind ik het een beetje raar om te kiezen voor HipHop "omdat die code zo groot is". De grootte van je codebase zegt niks over hoe snel PHP kan zijn en als je toch gaat refactoren danwel opnieuw beginnen dan kun je net zo goed een goed project opzetten in PHP. Als je alleen HipHop hebt geïnstalleerd om de bestaande code te compilen, dan heb ik niks gezegd.

[Phoib]

armageddon_2k1 schreef op zaterdag 28 januari 2012 @ 12:07:
[...]


Wait what?? Jij bent dan straks de enige in het bedrijf die dus eventueel met de omgezette code zo kunnen werken en de quirks begrijpt van hem omzetten? Als er één manier is om je veel problemen op de hals te halen is het wel als enige verantwoordelijk te zijn voor een enorme codebase.

HipHop compileert het meteen ook. De hele bedoeling van het programma is om je PHP code te behouden, en Hiphop als tool te gebruiken om het sneller in te kunnen zetten.

NMe schreef op zaterdag 28 januari 2012 @ 12:23:
Sowieso vind ik het een beetje raar om te kiezen voor HipHop "omdat die code zo groot is". De grootte van je codebase zegt niks over hoe snel PHP kan zijn en als je toch gaat refactoren danwel opnieuw beginnen dan kun je net zo goed een goed project opzetten in PHP. Als je alleen HipHop hebt geïnstalleerd om de bestaande code te compilen, dan heb ik niks gezegd.

Alleen om de huidige code te compilen. Het managment weet dat het sneller kan, en het wordt aangemoedigd om bestaande code te versnellen. Maar alles opnieuw beginnen? "Geen denken aan. Er zijn nog genoeg bestaande projecten om uitgevoerd te worden, we hebben er geen tijd voor."
Zelfs het opzetten van de index-test gebeurde al min of meer in het geniep

[Voutloos]

Phoib schreef op zaterdag 28 januari 2012 @ 13:41:
[...]

HipHop compileert het meteen ook. De hele bedoeling van het programma is om je PHP code te behouden, en Hiphop als tool te gebruiken om het sneller in te kunnen zetten.

Nee, dat is de best case, een utopie. Realistisch gezien zal je wel af en toe je PHP comfort zone moeten verlaten ivm debuggen, segfaults etc. En daarin is het vertrouwen op 1 persoon een behoorlijk groot risico.

[Phoib]

Voutloos schreef op zaterdag 28 januari 2012 @ 14:39:
[...]
Nee, dat is de best case, een utopie. Realistisch gezien zal je wel af en toe je PHP comfort zone moeten verlaten ivm debuggen, segfaults etc. En daarin is het vertrouwen op 1 persoon een behoorlijk groot risico.

Met de kwaliteit code die er geproduceerd wordt in het bedrijf ben ik al verbaasd dat de index-pagina laadt zonder segfaults, dus ik vermoed dat er al checks in het model uitgevoerd worden, voordat de C++ gegenereerd wordt. De gegeneerde makefile van 60k regels gaf mij in ieder geval weinig hoop om even wat code door te zoeken om even een segfault op te zoeken. Zelf gebruikt facebook er een interpreter voor, en ze zijn bezig met een virtual machine om HPHP gegenereerde code on-the-fly uit te voeren en te checken.

Het is sowieso nu nog een test, en er kan altijd besloten worden om er niet mee door te gaan, wegens "totaal-gebrek-aan-c++-kennis-buiten-mij-om", of licentieproblemen.

[Soultaker]

Phoib schreef op zaterdag 28 januari 2012 @ 01:01:
En dan nu mijn vraag... Hiphop wordt verspreid onder de CC-BY-SA license, die hier wordt vermeld: http://creativecommons.org/licenses/by-sa/3.0/deed.nl Nu ben ik geen advocaat of rechterlijk geschoold, maar het werk moet onder dezelfde licentie gedeeld worden. Betekent dit ook dat alle code, gecompileerd door HPHP, ook onder die licentie verspreid moet worden?

Om kort te zijn: ik denk van niet.

Maar hoe kom je erbij dat er een CC-licentie van toepassing is op de code? Die licenties zijn meestal niet voor programmacode bedoeld. Een blik in de broncode suggereert dat de PHP license gebruikt wordt.

Die beantwoord de kernvraag (is een programma gecompileerd door HPHP een "afgeleid werk" van HPHP?) ook niet, maar ik denk dat je er vanuit mag gaan dat je je gecompileerde programma's gewoon mag deployen zonder ze openbaar te maken, aangezien dit de interpretatie is die al jaren bij soortgelijke gevallen gebruikt wordt (bijvoorbeeld bij programma's gecompileerd met GCC).

[Phoib]

Soultaker schreef op zaterdag 28 januari 2012 @ 18:45:
[...]

Om kort te zijn: ik denk van niet.

Maar hoe kom je erbij dat er een CC-licentie van toepassing is op de code? Die licenties zijn meestal niet voor programmacode bedoeld. Een blik in de broncode suggereert dat de PHP license gebruikt wordt.

Die beantwoord de kernvraag (is een programma gecompileerd door HPHP een "afgeleid werk" van HPHP?) ook niet, maar ik denk dat je er vanuit mag gaan dat je je gecompileerde programma's gewoon mag deployen zonder ze openbaar te maken, aangezien dit de interpretatie is die al jaren bij soortgelijke gevallen gebruikt wordt (bijvoorbeeld bij programma's gecompileerd met GCC).

Ik zag op deze pagina dat de licentie CC-BY-SA is. Ik had echter iets beter moeten lezen, want deze licentie gaat over de Wiki tekst...

Excuseer me even terwijl ik mij in een hoekje terugtrek en me stom voel...

[Cartman!]

Ik wil er zeker opnieuw naar kijken als er ondersteuning is voor PHP5.3 want dat is onze vereiste voor Doctrine 2 namelijk. Bij Hyves zijn ze het ook gaan gebruiken en daar waren de developers enthousiast over de enorme boost in performance wat toch betekent dat je een hele zooi servers uit de roulatie kan halen, dat scheelt weer knaken.

[Kajel]

Het lijkt mij persoonlijk meestal een voorbeeld van "kleine stap vooruit, enorme stap terug", als je de OO voordelen van PHP5.3 moet inleveren om je code sneller uit te kunnen voeren. Je levert dan in de praktijk in op ontwikkel-snelheid, en daar krijg je performancewinst voor terug.
Ik denk dat een bedrijf als Hyves zich verkijkt op de nadelen t.o.v. de voordelen, en wat al te gemakkelijk Facebook achterna gaat.

Het grote verschil - en dat realiseren veel mensen zich niet - is dat de codebase van Facebook voor een groot deel helemaal niet uit PHP bestaat. Bij Facebook kiezen ze voor elk stukje "functionaliteit" de juiste bijpassende programmeertaal. Het backend bestaat grotendeels uit Java en C++, de chatclient is Erlang, etc. PHP wordt voornamelijk gebruikt voor de laag tussen het backend en het frontend. Eigenlijk de laag die de communicatie verzorgt tussen het frontend en de echte backend businesslogic (die dus in C++ en Java geschreven is). Omdat PHP daar dus een minder grote taak heeft, is de keuze makkelijker om bepaalde OO principes die met PHP5.3 mogelijk worden, links te laten liggen.

Overigens moet daarbij gezegd worden dat je met HipHop enkel wint aan CPU tijd. Het zal weinig tot niks doen voor je geheugengebruik, de tijd die gaat zitten in DB queries, de internetverbinding etc. Bij het bedrijf waar ik werk, hebben we ook eens naar HipHop gekeken, maar kwamen tot de conclusie dat op de dedicated server die we gebruiken, CPU totaal niet de bottleneck was, maar meer de DB queries. Iets waar Memcached een oplossing voor bleek te zijn.

[Phoib]

Kajel schreef op zondag 29 januari 2012 @ 14:02:
Het lijkt mij persoonlijk meestal een voorbeeld van "kleine stap vooruit, enorme stap terug", als je de OO voordelen van PHP5.3 moet inleveren om je code sneller uit te kunnen voeren.

C++ is ook OO? Bovendien gebruikten we geen PHP5.3, maar (uit m'n hoofd) 5.2

Onze bottleneck ligt niet bij DB gebruik. Een gemiddelde "trage" pagina duurt ongeveer 15 seconden om te laten, waarvan 800msec aan DB queries. Die pagina heb ik nog niet uit kunnen testen onder HPHP, misschien morgen.

[kwaakvaak_v2]

@kajel Wat is behalve een namespace en closures dan nog meer een 5.3 voordeel wat je in moet leveren als je 5.2 OO wel kunt gebruiken?

[Voutloos]

Phoib schreef op zondag 29 januari 2012 @ 17:27:
Onze bottleneck ligt niet bij DB gebruik. Een gemiddelde "trage" pagina duurt ongeveer 15 seconden om te laten, waarvan 800msec aan DB queries. Die pagina heb ik nog niet uit kunnen testen onder HPHP, misschien morgen.

Voor wat voor rocket science hb je die 14.2s nodig? Weet je zeker dat daar niet genoeg te verbeteren of te cachen valt? Heb je er uberhaupt al een keer een profiler op los gelaten?

Hint: Als je zegt dat er geen laaghangend fruit is ben ik staat om je niet te geloven.

[ Voor 9% gewijzigd door Voutloos op 29-01-2012 22:01 ]

[YopY]

Sowieso, een pagina die 15 seconden duurt om te verwerken is óf heel complex, óf heel slecht geprogrammeerd, óf heel erg groot. Of een combinatie van die drie. Ik kan me er iig geen voorstelling van maken.

[Cartman!]

kwaakvaak_v2 schreef op zondag 29 januari 2012 @ 18:31:
@kajel Wat is behalve een namespace en closures dan nog meer een 5.3 voordeel wat je in moet leveren als je 5.2 OO wel kunt gebruiken?

Als je gebruik maakt van libraries die leunen op namespaces dan heb je weinig keus, zoals ik als voorbeeld al aanhaalde: Doctrine 2 vereist PHP5.3 en Doctrine 2 is

En 15 seconden rendering voor een gemiddelde pagina is best bizar lang inderdaad, kan me niet voorstellen dat er niks te cachen valt..

[Gomez12]

Phoib schreef op zondag 29 januari 2012 @ 17:27:
[...]
Onze bottleneck ligt niet bij DB gebruik. Een gemiddelde "trage" pagina duurt ongeveer 15 seconden om te laten, waarvan 800msec aan DB queries. Die pagina heb ik nog niet uit kunnen testen onder HPHP, misschien morgen.

Dan zou ik niet naar hphp gaan kijken, maar eerder naar wat er fout zit in jullie structuur /gedachtengang.

Ik acht de kans onnoemelijk klein dat je hier echt grote performance winst uit gaat halen. 15 sec php lijkt mij een heel erg extreme edge-case (waar hphp weer andere problemen kan veroorzaken), het lijkt mij eerder dat je gewoon ergens extern op zit te wachtten (I/O / cpu) wat het langzaam maakt.

[kwaakvaak_v2]

Cartman! schreef op zondag 29 januari 2012 @ 23:02:
[...]

Als je gebruik maakt van libraries die leunen op namespaces dan heb je weinig keus, zoals ik als voorbeeld al aanhaalde: Doctrine 2 vereist PHP5.3 en Doctrine 2 is

Als doctrine 2 uiteindelijk de enige echte showstopper is om hiphop te gebruiken is daar vast wel wat aan te doen als de nood hoog genoegt is.

Maar ik ben het met je eens dat bij een page request van een 10 a 15 seconden eerst op andere vlakken moet gaan optimaliseren, want dan stinkt de code of je platform nog harder dan een vuilnisbelt in de zomer.

[Freeaqingme]

Hangt er wel van af wat die pagina dan doet. Ik heb wel eens een actie gehad die 1,5 miljoen facturen moest uittuffen. Dan was een paar minuten best acceptabel

[Gomez12]

Freeaqingme schreef op maandag 30 januari 2012 @ 19:15:
Hangt er wel van af wat die pagina dan doet. Ik heb wel eens een actie gehad die 1,5 miljoen facturen moest uittuffen. Dan was een paar minuten best acceptabel

Maar dan zat je zeer waarschijnlijk te wachten op I/O of db of iets anders, maar zeer waarschijnlijk niet op php zelf. Hphp gaat niet je randprocessen versnellen, het versnelt enkel maar php. Als dus van die 15 seconden er 0,5 sec in php-tijd gaat zitten dan kan het wel 100x versneld worden, maar nog steeds zit je 14,5 seconden te wachten...

[kwaakvaak_v2]

Freeaqingme schreef op maandag 30 januari 2012 @ 19:15:
Hangt er wel van af wat die pagina dan doet. Ik heb wel eens een actie gehad die 1,5 miljoen facturen moest uittuffen. Dan was een paar minuten best acceptabel

Klinkt meer als een klusje voor gearman dan voor hiphop

[Freeaqingme]

Excuus. Het had weinig met hphp te maken Mijn enige punt was dat 15 seconden enkel langzaam is als de context waar die laadtijd zich in bevindt dat voorschrijft.

[Cartman!]

kwaakvaak_v2 schreef op maandag 30 januari 2012 @ 19:08:
Als doctrine 2 uiteindelijk de enige echte showstopper is om hiphop te gebruiken is daar vast wel wat aan te doen als de nood hoog genoegt is.

Klopt. Bij projecten waarin we gebruik maken van Zend Framework valt het echter ook af want die gebruikt eval() voor de views en dat wordt niet ondersteund. De stateless gateway die hebben geschreven maakt gebruik van reflection en die wordt ook niet ondersteund. Op dit moment loont het voor mij niet om alles om te schrijven om simpelweg HPHP eens te proberen dus. Jammer want het lijkt me wel leuk het gewoon eens te proberen.

[alienfruit]

Doctrine2 + Symfony2 =

[Cartman!]

En hoe pas jij daar HPHP op toe? Nu voegt je comment niet echt iets toe zegmaar...

[Kajel]

Cartman! schreef op zondag 29 januari 2012 @ 23:02:
[...]

Als je gebruik maakt van libraries die leunen op namespaces dan heb je weinig keus, zoals ik als voorbeeld al aanhaalde: Doctrine 2 vereist PHP5.3 en Doctrine 2 is

En 15 seconden rendering voor een gemiddelde pagina is best bizar lang inderdaad, kan me niet voorstellen dat er niks te cachen valt..

Sorry voor mijn late reactie, maar Cartman omschrijft eigenlijk wel het punt wat ik wilde maken. Namespaces en Closures zijn constructs die er eindelijk voor zorgen dat je pas _echt_ goed OO kunt programmeren in PHP (maar da's ongetwijfeld een smaakkwestie van mijn kant).
Daarbij blijft mijn punt: de uitvoersnelheid van PHP (Lexing, parsing etc) is 9 van de 10 keer echt niet de bottleneck bij gemiddeld gebruik. HipHop is dus enkel interessant indien alle andere factoren - zoals DB, wat vaker de bottleneck vormt - al optimized zijn.

Ik geloof echt niet dat HipHop de oplossing gaat zijn bij de pagina met een laadtijd van 15 seconden.

Gomez12 schreef op maandag 30 januari 2012 @ 20:33:
[...]

Maar dan zat je zeer waarschijnlijk te wachten op I/O of db of iets anders, maar zeer waarschijnlijk niet op php zelf. Hphp gaat niet je randprocessen versnellen, het versnelt enkel maar php. Als dus van die 15 seconden er 0,5 sec in php-tijd gaat zitten dan kan het wel 100x versneld worden, maar nog steeds zit je 14,5 seconden te wachten...

Precies dit dus! Database, IO etc is meestal de bottleneck, niet PHP. En HipHop is enkel een oplossing voor het laatste.

Nog een edit: Mensen doen wat gemakkelijk over het afschrijven van frameworks zoals Doctrine, Symfony en Zend om HipHop te kunnen gebruiken. Het punt is dat die frameworks je ontwikkelsnelheid bij goed gebruik drastisch kunnen verhogen, en dat vaak meer waard is dan de theoretische performance winst die HipHop kan opleveren (als alle andere bottlenecks opgelost zijn!). De reden dat Facebook dat wel kan, is omdat PHP maar een (klein) onderdeel is van de totale stack. Facebook "draait" niet op enkel PHP. Dan hoef je niet je totale applicatie te herschrijven, overal bv eval() te vervangen, andere oplossingen voor reflection gebruiken etc, om HipHop te kunnen gebruiken. Het betreft dan slechts een deel van je applicatie die aangepast moet worden.
In de meeste voorbeelden in dit topic, bestaat het hele backend volgens mij uit PHP. We hebben het over PHP applicaties, dus dan is het opgeven van een framework waarop je totale applicatie gebouwd is, geen optie. En ook als je aan een nieuw project begint, en dat gehele project is in PHP, is het vaak ondoenlijk om al die frameworks links te laten liggen, om maar HipHop te kunnen gebruiken

[ Voor 46% gewijzigd door Kajel op 05-02-2012 15:05 . Reden: verhaaltje over frameworks ]