Verbeterde php-engine moet flinke prestatieverbeteringen brengen

Optimalisaties aan de php-engine, waaronder bij het geheugenbeheer, leveren volgens php-ontwikkelaar Dmitry Stogov snelheidswinsten van gemiddeld 10 tot 30 procent op. Zo zou Wordpress 3.6 circa 20 procent sneller draaien.

Stogov werkt al jaren aan de ontwikkeling van php en is onder andere betrokken geweest bij het Zend Framework. Samen met andere ontwikkelaars heeft de developer zich steeds meer gericht op het sneller maken van php, onder andere door aanpassingen in de php-engine en OPcache. In een poging toekomstige php-versies nog rapper te laten draaien is Stogov onder andere met mechanismes als jit-compiling aan de slag gegaan. Na maanden van werk heeft Stogov de eerste resultaten openbaar gemaakt.

Volgens de php-developer kan er flinke winst worden behaald door het geheugenbeheer in de php-engine te verbeteren. Veel details geeft Stogov nog niet, maar hij beschrijft de wijzigingen als aanpassingen aan de kelder en het fundament terwijl het bovenliggende huis grotendeels ongemoeid is gelaten. Ook heeft hij enkele benchmarkresultaten gepubliceerd die een aanzienlijke prestatiewinst laten zien. Zo weet het populaire opensource-cms Wordpress 3.6 20 procent meer requests per seconde te verwerken en Drupal 6.1 draait 11,7 procent sneller. De gemiddelde prestatiewinsten bij het draaien van php-applicaties zouden tussen de 10 en 30 procent liggen.

Stogov vraagt in een posting aan andere php-developers om de nieuwe code te testen. Ook geeft hij aan dat de verbeterde php-engine nog niet klaar is. Zo zijn er de nodige bugs en niet alle extensies worden ondersteund. Ook zou de developer nog enkele ideeën hebben voor verdere optimalisaties. Uiteindelijk zal de code vermoedelijk opduiken in een toekomstige release van php 5.7.

Reacties (67)

Is dit te merken voor de doorsnee internetter? Zullen delen van websites nu sneller laden?

De vraag is of je het sowieso al merkt of een pagina in 0.2 of in 0.6s output genereerd (alleen html). Daarbij gaat dit voornamelijk om het eerste stukje in het proces. De server geeft na jouw request een stuk html terug aan je browser. Dit zal iets versnellen.

Daarna moet je browser deze html omzetten in iets wat je op je scherm ziet. Hiervoor moeten nog heel veel andere bestanden (css, js, images) opgehaald worden. Dit duurt vaak veel langer dan de generatie van de html zelf. Om nog maar te zwijgen over alle ads die op een pagina geladen moeten worden, dat zijn de echte trage dingen.

Het is voornamelijk een voordeel voor (drukke) site eigenaren. Deze kunnen immers met dezelfde hardware meer pagina's per seconde tonen. Ze hebben dus minder servers nodig voor dezelfde hoeveelheid page views.

Amazon heeft dit in 2006 uitgebreid onderzocht en de conclusies uit dit onderzoek waren dat ze al 1% meer conversie behaalden bij een snelheidsverbetering van 100ms. Dus het is wel degelijk interessant om hier aandacht aan te besteden. Alle kleine beetjes helpen en als je alles goed optimaliseert ( cachen, parsen, compressen etc ) dan kun je toch al redelijk wat winst behalen. Vaak wordt er nogal het een en ander vergeten door het gros van de developers ( of het budget leende zich hier niet voor ). En 100ms is natuurlijk niks, het gros van de sites kan makkelijk 1sec winst behalen.

Speed optimization wordt erg vaak onderschat en bedrijven pompen dan veel tijd en geld in content marketing en conversie optimalisatie, maar vergeten één van de belangrijkste aspecten van conversie optimalisatie n.l. de snelheid.

Source: Amazon - Make Data Useful (2009)

[Reactie gewijzigd door quintox op 6 mei 2014 14:07]

Begrijp me niet verkeerd, snelheid is super belangrijk maar of je daar als gebruiker (actief) iets van merkt is twijfelachtig. Als ik bijvoorbeeld nu naar de Amazon pagina kijk dan duurt het 18.36sec voordat deze volledig geladen is. Hiervan is `slechts` 0.8s nodig voor de initiele html. Als je deze 20% sneller kan laten worden door deze optimalisatie dan duurt het nog steeds 18.2sec voordat de pagina geladen is. Of een gebruiker dat merkt?

Als die cijfers van 8(!) jaar geleden nog steeds kloppen dan valt er nog heel veel te winnen voor Amazon.

Zoals iemand anders al zegt in deze thread, er zijn waarschijnlijk veel betere (makkelijkere) manieren om een site sneller te maken. Bijvoorbeeld het aantal en soort database queries, beter formaat afbeeldingen, beter js. Een gebruiker zal dan ook (m.i.) weinig merken van deze update.

Het is natuurlijk een moment opname die 18.2sec en ik denk dat het te wijten val aan je eigen lijn. De resultaten die ik krijg zijn:
GTMetrix - 2.5sec
Webpagetest - 3.13sec
tools.pingdom.com - 1.4sec

Sites tussen de 1 en 3.5sec zijn extreem snel, dus geloof maar dat Amazon elk kunstje wel toepast zo ongeveer. En het lijkt me sterk dat alle 3 de speedtests zoveel afwijken ( het beste is natuurlijk een analytics meting over een bepaalde periode ).

Het onderzoek van 8 jaar geleden is alleen nog maar relevanter geworden met de groeiende mobiele markt en de noodzaak naar responsive designs. De prognose is zelfs dat mobiel gebruik groter zal zijn dan desktop gebruik rond +/- 2016. De relevantie van speed optimizing zal hierdoor alleen maar sterker worden. Of je 0.5sec bewust ervaart, weet ik niet, maar er zijn genoeg voorbeelden/onderzoeken die aantonen dat het een gunstig effect heeft op je conversie percentage dus het zal dan onbewust toch iets teweegbrengen. Daarnaast mag het dan wel een oud onderzoek zijn, het wordt nog steeds door bijna alle autoriteiten op het gebied van SEO/Conversion als grote voorbeeld gebruikt.

[Reactie gewijzigd door quintox op 6 mei 2014 14:42]

De lijn waar ik nu zit is inderdaad niet zo snel. Webpagetest komt bij mij uit op 5.9 (1st time!) document complete en 9.1 sec. Als je dan 0.16 sec kan winnen door deze update zal je daar als gebruiker niet echt iets van merken.

Bij tools.pingdom.com loopt de teller soms achteruit dus die vertrouw ik niet zo....

Begrijp me niet verkeerd, ik ben een grote speed freak en kan (als ik het rustig heb) een dag bezig zijn om oude code weer eens te optimaliseren en er zo een paar honderdsten van af te halen. Ik ben dan ook erg blij met elke (snelheids) update maar voor de gewone gebruiker zal het vaak weinig merkbaar effect hebben omdat het PHP gedeelte tegenwoordig maar een heel klein percentage van de load time is.

Dat klopt, je hebt gelijk dat PHP hier weinig extras aan zal bijdragen, bijna alle speed optimization tweaks hebben met de HTML/Caching/Server te maken. Maar 0.16sec is toch weer 0.16sec! Het lijkt wellicht alsof 0.16sec weinig effect zal hebben, maar volgens verschillende bronnen "kan" dat dus toch écht tot 1.8% meer revenue/conversie resulteren ( iig bij Amazon ). Dit is een behoorlijk resultaat voor maar 0.16sec. Gevoelsmatig is het moeilijk voor te stellen dat het zo'n groot effect heeft en het hangt natuurlijk ook af van het type site en de doelgroep ( en amazon is natuurlijk gigantisch ), maar het is overduidelijk dat het erg onderschat wordt terwijl het toch echt aangeeft dat zelfs een ontzettend kleine wijziging zoals 100ms al zo'n groot effect kan hebben op je totale conversie. Deze resultaten zijn uitvoerig getest met Analytics en A/B tests over een langdurige periode, het is behoorlijk onderbouwt.

Sowieso loopt het al snel op als je alles bij elkaar gaat tellen:
0.16 zou enkel de php engine zijn, tel daar nog eens de snelheidswinsten van de js, images, css files, http requests etc bij op. Dan zijn die 0.16 toch weer mooi meegenomen

Pingdom gebruik ik normaliter ook nooit, enkel webpagetest, gtmetrix en pagespeed. Pingdom is erg willekeurig. Maar alleen zijn enkel moment opnames en nooit een accurate indicatie voor de daadwerkelijk speed.

[Reactie gewijzigd door quintox op 6 mei 2014 15:26]

Het gaat ook vooral om het zien van iets voor de gebruiker. Als een website in 3 seconden laad en pas de aller laatste seconde wat wordt getoont is minder dan een website die bijv. in 6 seconden laad maar waar in de eerste seconde al een header en wat content zichtbaar is.

Voornamelijk beperkt tot niet merkbaar. De meeste traagheid komt voornamelijk door overhead van HTTP, de hoeveelheid HTTP requests die erbij komen (plaatjes e.d.) en het renderen van de pagina. Snellere PHP maakt slechts 1 van de 4 tijdrovende processen sneller.

[Reactie gewijzigd door Gamebuster op 6 mei 2014 12:29]

Plaatjes kan je veelal in je javascripts / pagina's embedden (base64) en js en css bestanden zijn vrij eenvoudig samen te voegen.

Zoals com2,1ghz zegt maakt het alles wel trager, base64 is vaak nogal wat groter dan het daadwerkelijke plaatje.
Ten tweede zorg je dat de browser de plaatjes niet meer kan cachen (het zit middels in de pagina zelf), en kunnen dus niet gebruikt worden in de "volgende pagina" (het zal hier dus weer in de html verwerkt moeten worden".

Wat samenvoegen betreft, het is misschien mogelijk om plaatjes in 1 grote atlas te verwerken en deze met css-coordinates eruit te halen. Als je dat in combinatie met goede server-side caching zou toepassen, zou het nog een prestatiewinst zijn?

Zoals com2,1ghz zegt maakt het alles wel trager, base64 is vaak nogal wat groter dan het daadwerkelijke plaatje.
Ten tweede zorg je dat de browser de plaatjes niet meer kan cachen (het zit middels in de pagina zelf), en kunnen dus niet gebruikt worden in de "volgende pagina" (het zal hier dus weer in de html verwerkt moeten worden".

Wat samenvoegen betreft, het is misschien mogelijk om plaatjes in 1 grote atlas te verwerken en deze met css-coordinates eruit te halen. Als je dat in combinatie met goede server-side caching zou toepassen, zou het nog een prestatiewinst zijn?

Website afbeeldingen ophalen is het probleem niet. Met een sprite los je alleen het probleem op dat je bij een hover of een andere event een afbeelding meteen kan tonen zonder het achteraf in te laden. De prestatiewinst is hierbij minimaal. Vooral bij de huidige bandbreedten en compressies van png files.

Wanneer afbeeldingen voor een hoge disk I/O zorgen, dan moet je echt kijken naar een oplossing als Varnish of een andere proxy-oplossing. Of zelfs een image server op een ander domein.

base64? Maak het nog trager allemaal.

Misschien eerst even onderzoek doen voordat je iets roept?

http://davidbcalhoun.com/...e-images-and-when-not-to/

Oké, je hebt een overhead van 33% maar het scheelt je wel in een http request.

Er wordt dan niets gecached door je browser. Dit kan zorgen een extreme load geven als het grote foto's zijn. Denk hierbij aan een foto van 5MB. Je document wordt ineens 5MB groter terwijl het ook als een apart resource opgehaald kan worden.

Dat kan prima. Als je kleine images via base64 in je CSS opneemt, wordt je CSS met 1 request geladen en met goede caching zijn die images dus ook gelijk goed gecached. Nee moet je niet doen met foto's van 5MB, maar met kleine layout achtige plaatjes van 1kb bijvoorbeeld werkt het prima. Met het voordeel dat je dus requests verminderd

Zulke dingen zijn dus veel gemakkelijker op te lossen met een aangepaste infrastructuur met bv. Varnish.

[Reactie gewijzigd door analog_ op 6 mei 2014 13:03]

Kun je dit toelichten?

Are you serious? JavaScript en CSS bundelen in ieder 1 bestand is inderdaad slim om te doen maar embedden?

Edit: verkeerd begrepen, ik dacht dat het ging om alle images en javascript embedden en zo HTTP aanvragen te besparen.

[Reactie gewijzigd door GewoonWatSpulle op 6 mei 2014 15:53]

Hij heeft het over het embedden van afbeeldingen als base64-data in CSS of in pagina's, niet over het embedden van JS- en CSS-bestanden. Bij kleine lay-out-afbeeldingen is dat een bijzonder slim idee. Tweakers doet dit ook, trouwens.

Maar dan worden ook je javascripts of pagina's groter, in principe maakt het qua grootte gewoon weinig uit. Je moet de data nou eenmaal overbrengen van server naar client. Enige wat je dan hebt is dat je minder bestanden in de wachtrij hebt, maar je wachtrij zal niet inkorten omdat de individuele processen langer duren. Verder is het ook niet echt aan te raden om alles in 1 css bestand te zetten omdat het dan aardig lang duurt voordat het geparsed is. Beter is dan om 1 voor de structuur te gebruiken en 1 voor de afbeeldingen, fonts en whatever. Anders is je initiële load te lang waardoor ook weer bezoekers afhaken.

Maar goed, zolang "webmasters" plaatjes blijven uploaden van vele mb's die eigenlijk maar een paar honderd pixels hoog en breed zijn, win je er sowieso weinig mee.

[Reactie gewijzigd door Martinspire op 6 mei 2014 12:46]

Niet in de nabije toekomst. Het is nog niet eens uit en zelfs als het uit komt kan het maanden tot jaren duren voor sites overstappen op de laatste versie. Ook zal je op veel sites te maken krijgen met een cache waardoor PHP zelfs niet eens gebruikt wordt.

Af en toe zal er een site een beetje sneller aanvoelen, maar dit is eerder voor webmasters en systeembeheerders. Dit betekent dat ze minder snel moeten upgraden om een goede performance te behouden. Het is een zeer welkome optimalisatie die waarschijnlijk wat geld kan uitsparen, maar voor de eindgebruiker blijft de impact vrij beperkt.

Een cache waardoor je PHP niet meer gebruikt? Leg eens uit... want dat raakt echt kant noch wal.

Varnish, Squid, etc. Zelfs NodeJS in bepaalde gevallen.

Ikzelf gebruik Varnish. Geeft pagina's in de cache terug op een fractie van een milliseconde en kan dit duizenden keren per seconde doen zelfs op enorm lichte servers. Is letterlijk enkele honderden keren sneller dan via Apache en PHP de hele CMS laten starten om een pagina te renderen.

Varnish wordt trouwens ook door Tweakers gebruikt als ik het me goed herinner. Echt een must have voor nieuwssites die serieus wat traffic kunnen krijgen.

[Reactie gewijzigd door Niosus op 6 mei 2014 14:14]

Hij heeft het over caching waarbij pagina's als HTML worden opgeslagen. Hoeft niet meer geparsed te worden en kan meteen geserveerd worden.

Bij sites die niet regelmatig worden geupdate en die toch aardig wat bezoekers krijgen, is het een mooie manier van performanceoptimalisatie. Als je je cache elke 15 minuten 1x opbouwd en dat serveert naar je bezoekers, is dat nog altijd sneller dan voor elke bezoeker dezelfde pagina genereren.

Maar dit is ook alleen bruikbaar als bezoekers niet inloggen en er verder ook geen interactie is (of je moet dingen uitsluiten maar dan is het effect grotendeels weg).

Als tweakers geen reacties zou hebben, zou je de nieuws-pagina's ook alleen hoeven te vernieuwen als er een nieuw bericht bij komt.

[Reactie gewijzigd door Martinspire op 6 mei 2014 12:50]

Dat is juist een heel slimme manier van caching, zeker als je gebruik maakt van reverse proxies. Met iets als ESI (Edge Side Includes) kun je ook slechts delen van een pagina laten cachen waardoor veel elementen 'statisch' (gecacht dus) zijn. Zodra de cache verloopt genereer je het pas opnieuw en stop je het opnieuw in cache.

Dat is echt wel een bagger slechte manier van caching. Tenzij je alleen static dingen serveert, maar dan heb je ook geen PHP nodig. Plaatjes/CSS/JS cachen is prima... maar HTML pagina's? Come on zeg...

Dat lost Varnish juist heel slim op. Je kan heel eenvoudig bepaalde resources selectief purgen. Denk bijvoorbeeld aan dit Tweakers artikel: Om de zoveel wordt een comment gepost. De server die de comment verwerkt kan een PURGE request sturen naar Varnish om deze pagina uit de cache te verwijderen. De volgende bezoeker krijgt dan terug een verse pagina met alle comments. Inclusief de laatste. Dit lijkt misschien inefficiënt voor een pagina die veel verandert, maar dat valt heel goed mee.

Stel dat er 10 bezoekers per seconde op een pagina zijn en elke 10 seconden wordt er een comment achtergelaten. Op die 10 seconden zijn er 100 requests waarna de cache gecleared wordt. De volgende 10 seconden moet de allereerste request via de server waarna de volgende 99 via de cache gaan. Je hebt dus een 99% hitrate op die pagina en dus 99% minder load op de server. Hoe meer bezoekers, hoe groter de hitrate.

Voor bijvoorbeeld het kopje vanboven als je ingelogd bent kan je Edge Side Includes gebruiken. Je moet dan voor ingelogde gebruikers in plaats van de hele pagina enkel en alleen hun naam gaan verwerken en tonen. Hierdoor heb je dezelfde optimalisatie als hierboven met voor elke ingelogde gebruiker een heel klein scriptje om te checken of ze ingelogd zijn.

Voor volledig dynamische websites werkt dit niet. Maar als je content hebt dat veel hits krijgt is dit een zeer goede manier om je servers te ontlasten.

Ik weet natuurlijk niet wat Niosus precies bedoelt, maar er zijn al verschillende manieren om PHP te cachen.

Wij gebruiken hiervoor iets vergelijkbaars, namelijk APC (http://www.php.net/manual/en/book.apc.php). Dat is een opcode cache voor PHP. Zorgt er simpel gezegd voor dat de PHP code die naar machinecode vertaald is, wordt gecached. Hierdoor hoeft deze dus niet iedere keer vertaald te worden, wat een flinke performance winst geeft. APC is bij ons zo ingesteld dat de cache van een bestand wordt verwijderd, als het PHP bestand is aangepast. Zo heb je er verder geen omkijken naar, maar het geeft heel wat performance winst. Vrijwel 100% van de hits wordt uit deze cache gehaald.

http://en.wikipedia.org/w...ative_PHP_Cache_.28APC.29

Leuke verbetering! PHP draaide IMO al vrij snel in vergelijking met andere scriptingtalen voor internet (Ruby on Rails en Python / Django bijvoorbeeld), maar extra snelheid is nooit weg natuurlijk. Complimenten voor deze prestatie.

Het verschil tussen WordPress en Drupal vind ik wel interessant. Zou dat iets te maken hebben met de enorm slechte / inefficiënte codebase van WordPress in vergelijking met Drupal, waardoor er bij WordPress sowieso al meer te halen is?

PHP op zichzelf is waarschijnlijk sneller dan Python/Django en Ruby On Rails, omdat er natuurlijk geen framework bij zit. Dit kan je dus niet zo direct vergelijken.

Vergelijk je verschillende frameworks (Django/RoR/Symfony/CodeIgniter), dan heeft een vergelijking al iets meer zin, en wat ik mij kan herinneren is dat Django vaak als snelste uit de bus kwam.

Oude bron: http://www.alrond.com/en/...-of-6-leading-frameworks/
Recentere Bron: http://blog.websitesframe...rameworks-benchmarks-192/
Meen te herinneren dat ik er meer heb gelezen, maar die kan ik niet zo 1, 2, 3 terugvinden.

Natuurlijk wel mooi dat de engine van PHP weer vebeterd wordt. Ik ben al een tijdje gelukkig van PHP afgestapt, maar het valt niet te ontkennen dat het nog steeds veel gebruikt wordt.

[Reactie gewijzigd door Sh4wn op 6 mei 2014 12:59]

Bij PHP bedoelde ik natuurlijk ook icm een framework, het is op PHP alleen een iets minder uitgemaakte zaak wélk framework je zou moeten gebruiken. Zelf gebruik ik vaak Zend Framework 2 wat me uitermate goed bevalt en zeer nette performance neerzet.

Ik heb het overigens niet over een ruwe vergelijking tussen de prestaties van de talen maar over het geheelpakket. Systemen die ROR of Python/Django gebruiken leveren mij als gebruiker een tragere ervaring op dan PHP/Zend doet. Python valt hierin nog redelijk mee maar ROR is echt om te huilen bij tijd en wijle.

Je kunt vanalles testen, maar een goede test opzetten moet ook herhaalbaar zijn door anderen. Plus, je moet kunnen vertellen welk onderdeel specifiek sneller is. Anders is het de zoveelste grafiek/benchmark die niets zegt.

Er zitten wat praktische verschillen tussen PHP en bijvoorbeeld Python/Django:
- PHP wordt per bezoeker overnieuw ingeladen, met alle framework includes, en alle state wordt overnieuw opgebouwd. De APC/opcode caching helpt hierbij wel mee.
- Python/Django blijft in het geheugen na het eerste request. De volgende request is effectief een "functie call" naar de web applicatie.

PHP is zeer snel in code vertalen naar interpreter instructies.
Python is wat trager in verwerking van interpreter instructies.

Django heeft een goed caching framework en hoeft bij afhandeling van een request weinig te doen. De template taal van Django is daarentegen traag, maar kun je vervangen.
PHP frameworks hebben het nadeel dat ze steeds overnieuw per request de state moeten opbouwen en alle gebruikte includes in het geheugen moeten inladen.

Ofwel, wat is er precies getest? Performance bij enkele requests? Performance bij load? Hoeveel concurrency? Hoe complex was de test? Gut-feeling tests zeggen zo weinig.

[Reactie gewijzigd door YaPP op 6 mei 2014 16:07]

Als het een kale drupal installatie betreft, dan is die inderdaad wat kleiner en daardoor ook sneller.

Op zich is 20% en 11% voor dergelijke cmssen een mooie verbetering, maar ik vraag me af of het voldoende is om PHP als populaire backend te houden voor dergelijke systemen. NodeJS is aardig in opkomst en zodra dat wat beter is te managen, gaat dat ook erg mooie dingen doen.

Plus dat die extra performance weer binnen notime wordt vervangen door een proces wat weer iets anders kan verbeteren, simpelweg omdat de performance er ineens is.

[Reactie gewijzigd door Martinspire op 6 mei 2014 12:44]

Ik werk zelf als professionele ontwikkelaar aan een (grote) desktop applicatie met gecompileerde c++ code:

• + compile time checking
• + performance
• - build tijden; geen runtime vervanging van code

Ik begrijp eerlijk gezegd niet goed waarom php nog steeds interpreted is, gezien de voordelen van compilatie. Ik heb wel eens een performance vergelijk gezien tussen c++ en php en daar zat een factor 5 tussen. Omdat php toch server based is lijkt me de uitrol ook geen probleem (dit i.t.t. client side java script). Is dit niet de richting waar php op moet?

edit: links heb ik ff niet paraat. Het was een praatje van een dude die bij Facebook werkte aan een jit compiler voor php.

[Reactie gewijzigd door gast128 op 6 mei 2014 12:56]

Runtime-Compiled-C++ een techniek die onder andere gebruikt wordt in de nieuwste Unreal Engine geeft je runtime vervanging van C++ code

Java heeft ook zoiets toch? Ik herinner met nog een interview met Markus Perrson waarbij hij in real-time in een live Minecraft instantie code kon aanpassen en uitvoeren.

Met interpreters die JIT-compilen en compiled code die ook kan interpreten heb je het beste van beide werelden. Mooie ontwikkelingen

Java heeft gewoon runtime hotswapping. Werkt soms wat slechter als je hele methodes gaat veranderen, maar prima voor constanten en een regeltje hier en daar.

Werk nu zelf aan een aantal OSGi based projecten waarbij bundle swapping zoveel tijd voor recompilen bespaart.

[Reactie gewijzigd door Cilph op 6 mei 2014 14:18]

Omdat interpreted talen ook zijn voordelen hebben:

+ Dynamic typing
+ Zoals je zelf al aangeeft geen buildtijd
+ Vaak grote standard libraries, en veel third party libraries

Deze drie factoren zorgen ervoor dat ik waarschijnlijk een bepaalde app sneller af heb, vergeleken met een vergelijkbare app in C++.

Voor grote projecten snap ik dat dynamic typing ook als nadeel kan worden gezien, omdat er natuurlijk een heleboel bugs al bij het compilen er uit worden gevist.

[Reactie gewijzigd door Sh4wn op 6 mei 2014 13:18]

Is anonymous typing zoals bij .NET niet een soort tussenweg die de belangrijkste voordelen van beide combineert?

Het verbaasd me eerlijk gezegd dat het maar factor 5 is, het zou toch meer moeten zijn. Hoe dan ook, PHP (maar bijvoorbeeld ook Python, Ruby) zijn daardoor wel zeer toegankelijk, wat vooral de penetratie van de technologie toch wel erg goed doet (het zal zoeken zijn naar een hosting provider die geen PHP aanbiedt).

Tja, als je een gecompileerde taal wil kun je ook gewoon geen PHP gebruiken, natuurlijk. Beide vormen hebben voor- en nadelen. De brute rekenkracht wordt vaak toch al niet verwacht van PHP applicaties en waar nodig kun je een en ander als PECL module compileren om de performance wel te verhogen.

Door de gehele taal te compileren wordt deployment een stuk lastiger, dan kom je met zaken als cross-compiling en linken in aanraking waar de meeste web-developers geen kaas van gegeten hebben. En dat terwijl PHP qua performance voor de meeste doeleinden gewoon voldoet, waardoor ik niet verwacht dat de PHP-community daar erg op zit te wachten.

Snelheid van code is mooi maar in mijn ervaring bepaald het algoritme uiteindelijk of een applicatie snel is of niet. Met andere woorden: een minderwaardig algoritme in snellere c++ code zou langzamer kunnen zijn dan superieur algoritme in langzame php code.

In php heb ik sneller een applicatie werkend dan in c++ en kan die extra tijd gebruiken om betere algoritmes te bedenken.

Een veelbelovende ontwikkeling op dit gebied is de HipHop VM van Facebook, zie http://hhvm.com. Dit is een JIT-compiler voor PHP en Hack (Hack is Facebook zijn static-typing variant van PHP). Ik vermoed dat je die bedoelde.

Rather than directly interpret or compile PHP code directly to C++, HHVM compiles Hack and PHP into an intermediate bytecode. This bytecode is then translated into x64 machine code dynamically at runtime by a just-in-time (JIT) compiler. This compilation process allows for all sorts of optimizations that cannot be made in a statically compiled binary, thus enabling higher performance of your Hack and PHP programs.

HHVM kan schijnbaar de 20 populairste PHP frameworks al out-of-the-box draaien en groeit snel in populariteit.

Wat ook handig zou zijn is dat je ontwikkeld met PHP interpreted en voor de live versie maak je gebruik van een gecompileerde versie.
Dus wel lekker snel ontwikkelen en testen en de voordelen van compilatie voor productie.

Mwa, echt snel is PHP niet: http://www.techempower.com/benchmarks/

Zeker populaire 'goede' frameworks zoals Symfony2 zijn ronduit droevig qua performance. Hiphop VM (hhvm) zorgt overigens voor best redelijke performance, maar is in de gelinkte benchmark niet met frameworks getest.

[Reactie gewijzigd door Henk Poley op 6 mei 2014 16:04]

Hoe verhoudt zich dit in vergelijking met Facebooks php-engine? Die schijnt ook 'veel' sneller te zijn dan de standaard engine en is nu open-source, als ik het me goed herinner. Zijn de doorgevoerde optimalisaties misschien deels uit de Facebookengine gehaald?

Je bedoelt de HipHop VM.
http://hhvm.com/

Eigenlijk meer (VM bytecode) compiler dan PHP engine; en o.a. bedoeld om C/C++ extenties in PHP te schrijven, niet alleen voor de snelheids verbetering.

Ik denk dat hij het heeft over de programeertaal "hack".
Geen idee of er ideëen hiervan zijn overgenomen, maar ik denk het niet

Hack en HHVM zijn met elkaar verweven. Hack draait op HHVM zoals Java draait op de Java VM.

Jammer.
Ik had liever gezien dat er meer consistentie in de naamgeving van functies in de PHP interpreterer kwam en dat die ook makkelijker te configureren is i.p.v. elk.ini bestand door te pluizen.

Het lijkt mij juist niet handig om de functienamen aan te passen. Enkel wanneer de oude functienamen gewoon blijven staan.

Zie het al voor me: even PHP upgraden. Oh wacht, nu moet ik (honderd)duizenden bestanden aanpassen omdat mijn CMS anders niet meer werkt.

En dan blijven programmeurs van de oude garde vaak nog steeds de oude functies gebruiken.

Edit: typo

[Reactie gewijzigd door Kontsnorretje op 6 mei 2014 19:08]

Hoezo? Bij andere talen zoals C++ en Java gebeurt het ook.

Per nieuwe versie van de standaard specificatie en/of standaard library worden bepaalde delen ervan als "deprecated" gemarkeerd. Dit wordt gedaan om zo de taal zelf te verbeteren omdat die deprecated functies en/of klassen vervangen zijn door andere die veiliger werken (strcpy vs strcpy_s (de C++11 ervan dat is, niet de MS versie)) of een hoger niveau van abstractie hebben (zoals bijv. Date.getDay() vs het nieuwe Calendar.get( Calendar.DAY_OF_WEEK ) in Java ).

Het is nooit zo dat de deprecates van de ene op de andere versie opeens niet meer werken. Er zit altijd wel één of meerdere versies tussen die warnings afgeeft voordat die deprecates werkelijk eruit gehaald worden en/of de compiler/interpreter gaat weigeren.

Net als hardware gaat software ook met z'n tijd mee. En dat moet ieder zelfrespecterende programmeur ook.

Drupal 6.1? Die versie is echt al 6 jaar oud. Waarom is geen recentere versie gebruikt zoals bij WordPress?

Zo recent is WordPress 3.6 niet. Ze zijn ondertussen bij versie 3.9. En gezien de grote verschillen, onder andere in de code base, weet ik niet hoe representatief de data zijn t.o.v. de huidige versie. Ook omdat er vrij veel opgeschoond is...

In mijn vrij rijke ervaring met web apps tunen is de snelheid van de middleware zelf (of dit nu PHP, een andere scripttaal, of Java is) nauwelijks een factor van belang. Doorgaans zijn er veel grotere winsten te behalen in zowel de database als de front-end, en van die 2 laatste, meestal de front-end. Een front-end die niet getuned is kan vaak met simpele ingrepen 4 keer minder belastend gemaakt worden.

Wordpress is een geval apart, deze genereerd verschrikkelijk veel database queries, wederom een geval waarbij PHP zelf niet het probleem is.

Iedere performance verbetering is uiteraard welkom, maar het is zaak problemen in de juiste volgorde op te lossen. Ik hoor wel eens PHP developers betwisten welke van 2 language constructs de snelste. Ze maken loopjes die het 10 miljoen keer uitvoeren en stellen dan dat de ene 200% sneller is. In absolute zin besparen ze in de praktijk net 1ms, terwijl de gebruiker 6 seconde zit te wachten op de database.

Natuurlijk is het een goede zaak om de interpreter sneller te maken alleen om pakketten welke niet goed zijn geconstrueerd sneller te laten draaien lijkt mij geen goed uitgangspunt dus zou dat zeker niet moeten worden genoemd als voorbeeld.

Zag laatst ook nog zoiets als Quercus, PHP gebaseerd op Java, levert een standaard snelheidswinst op van 4x. Alleen is het gekke dat het vergeleken wordt met PHP+APC, dus echt sneller is het blijkbaar niet alleen ivt php dan weer wel.

Mijn vraag is dan ook of dit zonder of met APC of andere runtime opcode optimizer is.

Klinkt allemaal heel leuk, maar gaat allicht nog wel een tijdje duren voor 5.7 GA is, en voor er hier dan ook daadwerkelijk gebruik van gemaakt gaat worden. Kijk even naar het performance verschil tussen 5.2/5.3 en 5.4/5.5. Die zijn minstens even groot dan deze vernoemde nieuwe verschillen. Feit is echter wel de dag van vandaag nog 52% van de websites die PHP draaien PHP 5.3 gebruiken en nog eens 28% versie 5.2.

Heeeeeel veeeeeel javascript om mee te beginnen.....

Check deze eens

http://www.homeandlearn.co.uk/index.html

Kan je met php en vb nog allebei de kanten op

PHP kan goed met databases communiceren en een inlogpagina maken met PHP is ook niet moeilijk.
Javascript word ook veel gebruikt.

Wil je echt makkelijk en leuk aan de gang moet je s kijken naar www.codecademy.com . Begin met html, css, javascript en daarna pas php.

Mooi naslagwerk vind je op w3schools.com

S6!

@Erwines, @S-Cript, @Teunwillems, @Newllander

Allen bedankt voor jullie reactie. Ik begrijp dat javascript onmisbaar is en zal daar nu aan beginnen alvorens met php te beginnen.

Thanks