Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 47, views: 44.761 •

Facebook is er in geslaagd om php-code negen keer sneller te laten draaien, dankzij gebruik van een just-in-time-compiler en een virtuele machine. De implementatie van Facebook, waarvan de broncode op GitHub is geplaatst, is vooral geschikt voor grote websites.

Facebook LogoNormaliter is php een geïnterpreteerde taal, waarbij de php-binary ervoor zorgt dat de code als machinecode wordt uitgevoerd, maar in de implementatie van Facebook wordt de php-code door een just-in-time-compiler naar bytecode vertaald. Omdat bytecode niet rechtstreeks op een cpu kan worden uitgevoerd, wordt die uitgevoerd in een virtuele machine. Die constructie is vergelijkbaar met Java en .NET. De combinatie van de virtuele machine en de just-in-time-compiler wordt door Facebook HipHop Virtual Machine genoemd; sinds dit jaar draait de constructie op alle Facebook-servers.

HHVM, waar Facebook drie jaar aan heeft gewerkt, zorgt ervoor dat php negen keer sneller kan draaien, zo zegt een medewerker van de sociale-netwerksite tegenover ComputerWorld. De virtuele machine is vooral interessant voor grote websites met een zware belasting; voor kleinere websites, zoals een simpel WordPress-blog, schat de Facebook-medewerker dat er sprake is van 'slechts' een vijfvoudige verbetering in snelheid.

De HipHop VM, waarvan de code op GitHub is geplaatst, is de opvolger van een ouder Facebook-project dat eveneens als HipHop door het leven ging. In die implementatie, die inmiddels is uitgefaseerd, werd php gecompileerd naar C++. Dat zorgde voor een verdubbeling van de snelheid van php. De implementatie met de jit-compiler en de virtuele machine blijkt niet alleen sneller, maar ook dynamischer. Het vertalen van php naar C++ is namelijk niet in alle gevallen mogelijk, omdat niet alle mogelijke bewerkingen kunnen worden voorspeld. Voor de jit-compiler hoeft code niet vooraf te worden gecompileerd: dat gebeurt op het moment waarop de code wordt uitgevoerd.

Reacties (47)

Maakt het uit?
In essentie ook correct maar die kon dubbel ge´nterpreteerd worden. De nieuwe titel beschrijft de methode beter.
HipHop was er al, HipHop VM is nieuw
'slechts' een vijfvoudige verbetering in snelheid.

Als je dit kunt bewerkstelligen op de grote providers die soms honderden sites op een server hebben draaien (allemaal weblogjes) Dan is dat als datacenter natuurlijk gewoon 5x zoveel inkomsten per server :+

Erg mooi dat facebook zich hier ook mee bezig houd. Zelf ben ik totaal niet thuis in het software wereldje (echt hardware tweakert) maar dit is een erg mooi concept zoals ik het nu kan beoordelen _/-\o_
Dan is dat als datacenter natuurlijk gewoon 5x zoveel inkomsten per server :+
Netwerkkosten daargelaten natuurlijk ;)
En het zal meer geheugen en mogelijk diskruimte kosten.

Ik betwijfel trouwens of rekentijd bij die datacenters de bottleneck is. Maar wie weet :)
Het werkt niet met alle standaard PHP code, deze snelheidswinst is grotendeels afhankelijk van de code kwaliteit en de installatie van HipHop for PHP is niet bepaald simpel (behalve als je exact dezelfde Linux distributie als Facebook gebruikt). Om alle websites op een webserver van een provider compatibel te maken zal een hoop werk nodig zijn.

Het zal waarschijnlijk pas nuttig worden vanaf het moment dat je minimaal 1 dedicated server voor je website nodig hebt, en dan nog is het waarschijnlijk goedkoper om een tweede server te huren dan om mensen in te huren om je code volledig aan te passen en te testen zodat het compleet werkt met HHVM (maar, kwa snelheids winst per pageview is het het meestal wel weer waard). Daar komt nog bij dat de installatie niet eenvoudig is en veel Apache modules vervangen moeten worden door andere dingen (zoals het populaire mod_rewrite).

De HipHop for PHP blog bevat een hoop informatie over hoe het werkt;
http://www.hiphop-php.com/blog/

[Reactie gewijzigd door Zerotorescue op 27 juli 2013 20:49]

Staat er al lange tijd, niet echt nieuws ofzo. Ik heb zelf wat gepiemeld met HipHop. Leuk voor als je iets nieuws gaat bouwen en de ontbrekende functies vermijd. Het is geen full replacement dus als je Drupal of Wordpress erop wilt draaien zonder te patchen dat zal niet lukken.

Verder leuk project, alleen jammer dat het zo'n floating target is op het moment (of misschien is dat nu juist voorbij met die VM). Er veranderde naar mijn mening nog teveel. Hopelijk trekt dit meer ontwikkelaars aan want er moet nog heel wat gebeuren. Er zijn overigens ook pre-built Ubuntu packages beschikbaar, gemakkelijk om te installeren.

Uit ervaring, als je APC gebruikt kom je erg dicht in de buurt van de performance van HipHip mocht het toch niet lukken om zo ver te komen met HipHop maar je wel die performance-gain wilt zien zul je zoiets moeten doen.
Als APC (wat niks anders doet dan de PHP byte code van een .php file cachen) dicht in de buurt komt van HipHop, is er nog een lange weg te gaan. HipHop is dus vergelijkbaar met Java 1.1.

FYI, er is ook een Java based implementatie voor de PHP interpreter: Quercus http://www.caucho.com/resin-3.1/doc/quercus.xtp en die claimt 4x performance in vergelijking met mod_php (dus in de buurt van APC). (note: quercus doet geen JIT voor PHP naar JVM bytecode).

[Reactie gewijzigd door elmuerte op 27 juli 2013 11:07]

Quercus hoeft ook niet per se JIT daarvoor te doen, ze zouden ook het JIT-gebeuren aan de JVM over kunnen laten door zelf de php-code te transformeren naar JVM-bytecode. Maar toen ik een paar weken geleden de code ervan bekeek, zag het er niet naar uit dat ze dat doen.

Op zich niet erg, maar daar zou ook bij Quercus dus nog een enorme winst te halen zijn. Dat gaat natuurlijk wel gepaard met erg ingewikkelde programmacode (PHP is niet bepaald de eenvoudigste taal om te compileren naar een andere taal). En daar zijn ze ook achter gekomen bij Facebook :P

Overigens doet Quercus wel een paar simpele optimalisaties tijdens de omzetting van de php-code naar een Quercus Program. Maar niets op de manier zoals de JVM het tegenwoordig doet of zelfs HipHop VM.
Eens, zelf compileren is een crime en daarna heb je iets dat maar zeer beperkt inzetbaar is. Kan me voorstellen dat voor facebook die de resources heeft om alles aan te passen aan hiphop het een uitkomst is. Maar voor gewone stervelingen is APC denk ik 10x beter: makkelijk te installeren en redelijk fool proof :)

De opmerking dat het vooral handig is voor grootschalige toepassingen snap ik niet zo, veelste veel een moving target en nog lang niet stabiel genoeg.
Tip: gebruik Opcache (hoort standaard bij PHP 5.5), n˛g eens veel sneller dan APC (+300% oid).
Opvallend dat jij als enige op OPcache wijst. Voor alle anderen: APC is passe, omdat de PHP-ontwikkelaars het niet stabiel kregen onder PHP 5.5. Ook voor oudere PHP versies (5.3 en 5.4) en voor Windows kun je beter overschakelen op OPcache.

Voor zelfbouwers:
https://github.com/zendtech/ZendOptimizerPlus

Voor Windows:
- meegeleverd met PHP 5.5
- http://windows.php.net/do...l/releases/opcache/7.0.2/ voor 5.3 en 5.4

Of je haalt mijn builds op via
http://www.apachelounge.com/viewforum.php?f=6

@TvdW: --enable-opcache hoef je in 5.5 niet eens toe te voegen (staat automatisch aan) en voor 5.3 en 5.4 zul je toch echt die broncode op moeten halen.

[Reactie gewijzigd door Jan-E op 27 juli 2013 15:12]

Voor zelfbouwers, gewoon "--enable-opcache" meegeven aan PHP's "./configure"-script. Niet handmatig met broncode gaan prutsen :)
Het hangt heel erg van je code en de hoeveelheid verkeer af, zoals ze ook uitleggen in een aantal blogs. Wikipedia gebruikt bijvoorbeeld ook HipHop omdat dit juist heel veel sneller is dan APC. Wordpress vereist trouwens ook maar een paar kleine wijzigingen.
Nog niet. Maar er is al wel een testversie, hihi.

[Reactie gewijzigd door TvdW op 27 juli 2013 11:47]

Serverfout, heh.
Heb jij het niet over de oude versie van HipHop ( de versie die een C++ compile van je php code maakte)?
Het is wel iets nieuws. Dit nieuwe project draagt dan wel dezelfde naam als het oude HipHop, maar werkt geheel anders :)
HipHop VM is ook al een aardige tijd in ontwikkeling hoor. Zie de diverse verhalen op Facebook. Maar het is inderdaad wel een voortborduursel op die omgeving die het in C++-code omzette.
Dit zal betekenen dat er minder servers nodig om dezelfde hoeveelheid verkeer te verwerken, servers kunnen meerdere aanvragen aan per seconden aan en pagina's zullen sneller gerenderd worden.

Ik zie dat HHVM alleen beschikbaar is voor Ubuntu, Debian, CentOS en FreeBSD. Vraag me af of er ooit een Mac/Windows versie zal komen (wat ik betwijfel).

Hier is een link met tips om HipHop VM te optimaliseren:
http://www.hiphop-php.com/wp/?p=713

Code zal dus altijd in functies/classes moeten staan wil de JIT Compiler deze kunnen verwerken. Alle globale variabelen zullen niet verwerkt worden.

[Reactie gewijzigd door ZeroXT op 27 juli 2013 11:04]

En dat is eigenlijk een goed iets. Global variabelen hoor je alleen te gebruiken als je procedurele pagina's schrijft. Zodra je zelf code in classes gaat plaatsen, hoor je ook de configuratie in objecten bij te houden en deze bijvoorbeeld via dependency injection door te geven aan de 'page' classes..

HHVM zou eventueel ook onder Windows kunnen werken, maar HHVM verwerkt zelfs de HTTP(s) calls. Het vervangt dus IIS en Apache en dus zal HHVM niet snel onder Windows worden gebruikt..

Daarnaast had Facebook in 2009 2 eigen data centers en hadden ze al meer dan 60.000 Linux servers staan welke vooral PHP, Memcached en MySQL draaiden en sindsdien is ook Facebook overgestapt op document databases (NoSQL) via Cassandra.
Ik denk niet dat HHVM zinvol is om op Windows aan de gang te krijgen. Niemand gaat Windows gebruiken voor dit doort high-volume sites, niet eens om dat het gewoon niet aan de eisen voor dit soort kritieke infrastructuur voldoet, maar vooral om dat het niet flexibel is, en het ook nooit zal zijn.

Dus stel dat iemand HHVM voor Windows zou patchen en builden, dan heb je er niet echt iets aan, om dat het toch nooit op die manier in een productie omgeving terecht zal komen, en als je lokaal wil testen, dan kan je beter een VM met linux nemen (of gewoon op Linux ontwikkelen).

Wat Mac betreft is het een ander verhaal. Je kan hem al gewoon bouwen onder Mac OS X, om dat er qua technologie veel overlap is. Je hoeft geen rare fratsen uit te halen om het te laten werken.
Ik zou bijvoorbeeld op een OS X machine gewoon van github kunnen clonen, en daarna configure && cmake waarna (als de deps geinstalleerd zijn) de binaries gebouwd worden.

Wat de servers per pagina betreft (of pagina's per server); hoewel je in theorie minder servers nodig hebt denk ik dat het eerder een punt wordt om gewoon sneller te serveren. Stel dat je op een gegeven moment zo snel bent dat je geen wachtrij mee hebt is sneller niet heel belangrijk meer, maar capaciteit. Natuurlijk is facebook nog niet zo ver, maar wat servers betreft zullen er de komende tijd vooral nog servers bij komen ;)
zoals eerder aangegeven. Door APC te gebruiken kom je al aardig in de buurt van deze perfmance voor werkelijk 0.0 werk. Om dit systeem van facebook t implemetneren/installeren ben je ontzettend veel meer tijd kwijt en er zitten een hoop haken en ogen aan.
zoals eerder aangegeven. Door APC te gebruiken kom je al aardig in de buurt van deze perfmance voor werkelijk 0.0 werk.
Heb je de oude of nieuwe HipHop 'versie' gebruikt?

Op mijn werk gebruikten we PHP met APC en zijn overgestapt naar HipHop (oude versie) voor een advertentieplatform met 10 miljoen requests op drukke dagen en zagen zeer grote performance boost. Servers zaten op piek momenten langdurig tussen 75% ~ 100%. Met HipHop is dat nu 20% ~ 30%.

Ook zagen we in de responsetijden bij grotere aantallen concurrent users een (heel) groot verschil. Overigens ook bij kleinere aantallen concurrent users. :)

Maar goed, ik kan mij zo voorstellen dat de ene dienst meer baat heeft bij HipHop dan de andere dienst.

Of misschien andersom: de ene type dienst zal meer baat hebben bij APC dan de ander.
Wel gaaf, maar als het zo is, dat het een vergelijking is tussen PHP, zonder APC (of een andere) opcode cache, dan loopt de vergelijking wel wat scheef.

Op de meeste productie servers wordt APC wel ingesteld, omdat dit ook voor een aardige prestatie winst zorgt ten opzichte van ongechached uitvoeren van PHP.

Als je daarbij als developer nog rekening houdt met de APC caching mechanismes en niet teveel recursive / objecten calls doet in je code. Dan krijg je ook een aardig efficiŰnte code base, met een goede performance.

Daar heeft Facebook ook wel een aardige extensie voor gemaakt en als opensource uitgegeven overigens: xhprof http://pecl.php.net/package/xhprof

Die is sinds 20 mei 2013 weer bijgewerkt, en draait goed onder PHP 5.4, dat geeft een mooi overzicht van hoe code wordt uitgevoerd, welke functies worden aangeroepen en hoe vaak, per request.
Die constructie is vergelijkbaar met Java en .NET.
Dat is niet helemaal correct. Bij .NET (CLI languages) wordt de source code pre-runtime omgezet naar een soort bytecode, namelijk CIL. Die wordt dan met een JIT-compiler omgezet naar machine code, die ook gecachet kan worden en dus niet gewoon ge´nterpreteerd wordt door een VM bij runtime zoals o.a. het geval is bij de default implementatie van Lua. Bij HipHop lijkt dit wel het geval te zijn (volgens het artikel alleszins). HipHop lijkt ook nog de PHP source code bij runtime om te zetten in bytecode, in plaats van het vooraf te compileren.

[Reactie gewijzigd door lesderid op 27 juli 2013 11:31]

Sowieso is er een enorm verschil tussen Java/.NET en PHP: PHP is dynamically typed (voor zover je daar van kunt spreken). Omdat je daarmee niet hard kunt linken aan functies die worden aangeroepen, zal de performance altijd achterlopen op statically linked talen (zoals Java/.NET).

Ja, ik weet dat .NET een DLR heeft, maar het gebruik daarvan is meer uitzondering dan regel.
Sowieso is er een enorm verschil tussen Java/.NET en PHP: PHP is dynamically typed (voor zover je daar van kunt spreken). Omdat je daarmee niet hard kunt linken aan functies die worden aangeroepen, zal de performance altijd achterlopen op statically linked talen (zoals Java/.NET).

Ja, ik weet dat .NET een DLR heeft, maar het gebruik daarvan is meer uitzondering dan regel.
Dat is wellicht ook wat men bedoelt met:
Het vertalen van php naar C++ is namelijk niet in alle gevallen mogelijk, omdat niet alle mogelijke bewerkingen kunnen worden voorspeld.
Zou de mobiele app hier ook van kunnen gaan profiteren? Want dit is al vanaf het begin 1 groot drama met Facebook. Opnieuw nieuwsoverzicht laden op zaterdag en dan het laatste nieuws van donderdag zien bijvoorbeeld. |:(
Nou bij mij is de app elke dag traag. En eigenlijk ook elk tijdstip :P
Ga je met je browser naar m.facebook.com dan is gelijk alles geladen. Dus waar de app zijn data vandaan haalt is mij een groot raadsel want het gaat Řber langzaam.
Ik denk dat er iig routering problemen zijn. Als de app te lang doet over het laden van een plaatje en ik schakel van WiFi (upc) naar 3g (voda) dan laadt het wel direct. De mobiele website werkt wel altijd goed.
Het project mag dan weleens waar nog niet helemaal volwassen zijn. Maar ik kan dit alleen maar toejauichten. Een ding wat ik wel minder vind is dat het alleen te implementeren valt als een stand-alone server. betekend toch weer dat je het kan inzetten bij een nieuwe omgeving of een migratie traject, mocht het zo zijn dat het project volwassen is.

[Reactie gewijzigd door Typnix op 27 juli 2013 11:49]

Normaliter is php een ge´nterpreteerde taal, waarbij de php-binary ervoor zorgt dat de code als machinecode wordt uitgevoerd, maar in de implementatie van Facebook wordt de php-code door een just-in-time-compiler naar bytecode vertaald. Omdat bytecode niet rechtstreeks op een cpu kan worden uitgevoerd, wordt die uitgevoerd in een virtuele machine
Als ik dat zo lees moet die PHP-interpreter goed gaar geweest zijn...
Met die nieuwe oplossing wordt als ik het goed begrijp een tweede vertaalslag gemaakt, plus dat het in een VM draait die ook nog eens een abstractielaag vormt die enige conversie vereist en een lag veroorzaakt op alle lokale bronnen. Ik vind het allemaal nog niet erg geloofwaardig klinken. Dit heeft volgens mij meer weg van een reclamespotje, alhoewel me dat met zoveel FB gebruikers ook niet meer nodig lijkt.

[Reactie gewijzigd door blorf op 27 juli 2013 13:02]

Ah dan moeten Java en .NET ook erg traag zijn. Ik zou toch even Wikipedia erbij pakken en jezelf eens inlezen :)
Dat gaar valt wel mee, maar geinterperteerde talen zijn altijd langzamer dan gecompileerde talen.
Dus niet traag in absolute zin, maar traag in vergelijking met gecompileerde talen
Om een voorbeeld te geven, ik heb ooit een cruptografische challenge opgelost met een python script. De standaard python interpreter deed er 8 minuten over. Pypy, een python implemetatie in python doet JIT compilen, en draait dezelfde code in 40 seconden. Ik vind de claims van Facebook dan ook niet raar.

Op dit item kan niet meer gereageerd worden.



Populair: Vliegtuig Luchtvaart Crash Smartphones Google Laptops Apple Games Politiek en recht Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013