PHP vs HHVM - Silverstripe

Auteur Twisted Bytes op 11 Mei 2015

Hoe veel sneller is HHVM met een echt PHP framework? Dat is wat we in deze blog gaan bekijken. Een aantal weken geleden hebben we in een blog geschreven dat HHVM een interessante versnelling kan zijn voor websites of applicaties. Nu gaan we kijken wat het verschil is als je HHVM met een framwork gaat gebruiken. In dit geval Silverstripe.

De vorige blog was een eenvoudige vergelijking tussen PHP en HHVM. Daaruit bleek dat HHVM 70% tot 800% sneller kan zijn. Dat was een kleine test op basis van wat PHP functies, maar in de praktijk werkt het allemaal wat anders.

De praktijk heeft te maken met een database server, bestanden lezen, externe connecties naar api’s, en heel veel PHP bestanden die via includes gelezen en geparsed moeten worden. Deze activiteiten hebben een heel ander effect op de snelheid en juist daar ligt ook de kracht en een verborgen kwaliteit van HHVM. In deze test zijn twee opmerkelijke resultaten duidelijk geworden, maar daar later meer over.

TL;DR, naar de conclusie.

Setup

De test is uitgevoerd op het demo project van Silverstripe. Dit project bestaat uit een kant en klare Silverstripe site met een 15-tal pagina’s en bijbehorende inhoud en plaatjes. We hebben dit project uit GIT gehaald en geconfigureerd. Het resultaat is een standaard site die representatief is voor een eenvoudige PHP site of applicatie.

Voor de test hebben we een Apache jmeter testplan gemaakt. Dat bestaat uit een oplopend aantal threads, van 15 tot 300 in stappen van 15, die continue pagina’s opvragen van de site. Voor de vertaling van threads naar gebruikers is geen eenduidige rekensom te geven, maar een inschatting is dat elke thread 10-40 gebruikers zijn. Elke thread wacht namelijk niet voordat het een nieuwe pagina opvraagt en dat doen gebruikers wel.

Vervolgens hebben we de demo site op een standaard server geplaatst en alleen PHP en HHVM tussen de tests veranderd. Verder bleef de configuratie gelijk. PHP is getest met versie 5.6.7 en HHVM met versie 3.6.0. Na een test met PHP en HHVM is de server geupgrade naar een snellere om zo te zien of en hoeveel verschil dat maakt, dus “hoe schaalt het”. Zo zijn de volgende servers getest:

• 2 cpu cores & 2G geheugen
• 4 cpu cores & 8G geheugen
• 8 cpu cores & 64G geheugen

We testen alleen de dynamische content van de site. De statische content is voor een Apache in event-mode of Nginx eigenlijk geen probleem en dus niet interessant voor deze test.

Resultaten

De test levert als resultaat een lijst van grafieken op:

• response time
• Hoe snel reageert de applicatie “nu”
• hits/second & transactions per second
• Hoeveel antwoorden geeft de server per seconde
• response latencies over time & response times vs threads
• Hoe lang duurt een request, over tijd of vergeleken met het aantal threads
• transaction throughput vs threads
• Hoeveel antwoorden geeft de server per seconde vergeleken met het aantal threads

In totaal 6 grafieken. Om hier niet een enorme lijst van grafieken te laten zien gaan we alleen de meest interessante grafieken behandelen: response time en transactions per seconde. Mocht je de andere grafieken willen zien, kun je ons altijd emailen: [email protected]

2 cpu’s en 2GB geheugen

Dit zijn de resultaten van HHVM en PHP bij 2 cpu’s en 2G geheugen. Het is niet goed te zien, maar PHP heeft hier een maximum responsetijd van ongeveer 5500 milliseconden, 5,5 seconden. PHP heeft het echter wel moeilijk vanaf 240 threads. HHVM laat een ander beeld zien. Het loopt op tot ongeveer 5000 milliseconden maar heeft het niet echt moeilijk. Dat is een verschil van 10%.

Duidelijk is ook dat bij HHVM alle type pagina’s ongeveer even snel reageren, bij PHP zijn er duidelijk 3 lijnen te zien. Dit betekent dat voor PHP de ene pagina zwaarder is dan de andere, maar bij HHVM zijn ze zo goed als gelijk.

Van dezelfde test hebben we ook grafieken die het aantal transacties per seconde tonen.

PHP doet ongeveer 45 en HHVM 60 requests per seconde. Het verschil tussen PHP en HHVM is 33%. Het is interessant om te zien dat HHVM aan het begin moet opbouwen: dat is het effect van de compiler van HHVM. In de PHP grafiek is ook te zien dat op hetzelfde moment dat PHP het moelijk krijgt het ook meer mislukte requests produceert. Dat is roze lijn aan de onderkant.

Dat HHVM sneller is weten we langzaamaan wel, maar wat hier duidelijk te zien is hoe grillig de grafiek van PHP is vergeleken met die van HHVM. Dit is een indicatie dat HHVM de code gelijkmatiger uitvoert.

4CPU’s en 8GB geheugen

De test met 4 cpu’s en 8GB geheugen laat ongeveer hetzelfde beeld zien. PHP krijgt het moeilijk bij veel threads en HHVM niet. Het effect is wel minder. Dit suggereert dat PHP de extra processortijd wel kan gebruiken. In de conclusie komen we met een mogelijke verklaring van dit gedrag.

8CPU’s en 64GB geheugen

De laatste set van tests zijn gedaan met 8 cpu cores en 64GB geheugen. In dit geval heeft PHP op de piek ongeveer 1700 milliseconden nodig en HHVM 1100 milliseconden. Een verschil van ongeveer 55%. En PHP blijft het moeilijk houden boven 240 threads. 

Het aantal requests per seconde stijgt ook mee het aantal cpu’s. PHP haalt ongeveer 175 hit per seconde, HHVM begint bij 210 en daarna ongeveer 270 hits per seconde. Een verschil van ongeveer 54%.

Overzicht van de resultaten

 

Test	PHP	HHVM	Verschil
Max latency 2cpu & 2GB	5500 ms	5000 ms	10%
Max latency 4cpu & 8GB	4000 ms	2800 ms	43%
Max latency 8cpu & 64GB	1700 ms	1100 ms	55%
TX / second 2cpu & 2GB	45	60	33%
TX / second 4cpu & 8GB	75	110	47%
TX / second 8cpu & 64GB	175	270	54%

 

PHP en HHVM - geheugen gebruik

Een belangrijke waarneming tijdens deze test is dat HHVM onder load veel stabieler is dan PHP. Tegelijk hebben we gezien, maar niet in metingen meegenomen, dat het geheugen gebruik van HHVM relatief gelijk blijft.

Om dit uit te leggen moeten we uitleggen hoe de architectuur van PHP en HHVM verschillen op het nivo van het verwerken van een request. PHP verwerkt elk request in zijn eigen proces. PHP kun je op verschillende manieren aan een webserver koppelen: CGI, mod_php, fastcgi en php-fpm. We gaan niet in op de verschillen, maar bij elke methode wordt PHP in een eigen proces uitgevoerd. En elk proces heeft de volledige PHP runtime in geheugen. Als je dus 50 PHP requests parallel aan het verwerken bent heb je PHP 50 keer in geheugen. Bij onze tests waren de php-fpm processen ongeveer 25 MB groot. Dat is dus 50x25 = 1250MB.

HHVM doet het wat anders. Daar worden de requests afgehandeld door threads in 1 proces. HHVM doet aan caching en compiling waardoor het meer geheugen nodig heeft dan 1 PHP proces. We hebben gezien dat het HHVM process tussen de 180MB tot 350 MB geheugen gebruikt. Dit is relatief veel vergeleken met 1 PHP proces. Maar... Dit was ook het maximum geheugen dat het nodig had tijdens al onze testen. Bij 50 en 100 gelijktijdige requests blijft het ongeveer 350 Mb.

Wij denken dat dit dus ook het verschillende gedrag van PHP en HHVM verklaard. Tijdens de PHP tests moet het OS relatief veel beheer doen op het geheugen en de processen van PHP.

Bij de eerste test, met 2 cpu’s en 2GB geheugen, liep PHP tegen het totaal beschikbare heugen aan. Bij 200+ gelijktijdige requests had PHP alle 100 mogelijke php-fpm pool processen in gebruik en dat telt op tot meer dan 2GB geheugen. Daarom gaat het zo mis boven de 200 en minder op het moment dat er meer geheugen beschikbaar is.

Conclusie

Er is een korte en een lange conclusie. Eerst de korte:

• HHVM is sneller dan PHP. Het verschil zit tussen de 40% tot 60%. Dus niet zo extreem als een simpele test doet vermoeden, maar zeker een grote verbetering
• PHP gebruikt vanaf 8 tot 12 gelijktijdige requests meer geheugen dan HHVM.
• Bij veel gebruikers zal HHVM een betere gebruikerservaring bieden dan PHP doordat HHVM sneller en gelijkmatig requests beantwoord.

En nu de lange.

HHVM is sneller dan PHP. En de kans dat je drukke site onderuitgehaald wordt door PHP is groter dan door HHVM. PHP zal namelijk bij meer requests meer geheugen gaan gebruiken en op dat moment gaat het mis:

• Het aantal processen is gelimiteerd: de gebruikers zullen lang moeten wachten op een reactie of waarschijnlijk een foutmelding
• Het aantal processen is niet gelimiteerd: het geheugen gaat vollopen en de site wordt traag en gebruikers gaan foutmeldingen krijgen
• Het aantal processen is niet gelimiteerd en je hebt veel geheugen: de server gaat erg druk worden met beheren van al die PHP processen.

Van deze mogelijkheden is de laatste de beste, maar daar is een zware server voor nodig. En het is alleen van toepassing voor sites met veel bezoekers. Bij sites met maar een paar bezoekers is het, volgens ons, niet de moeite waard om HHVM te gaan gebruiken. Echter bij sites met veel bezoekers of waar af en toe veel bezoekers langs komen is het zeker aan te raden.

Zoals altijd met conclusies zijn er mits en maren. HHVM is niet volledig compatible met PHP, sommige extensies van PHP zullen (nog) niet beschikbaar zijn, HHVM vereist een iets andere manier van inrichten van de server. En zo zijn er nog wel meer.

 

Testen met HHVM?

Wij zijn ervan overtuigt dat HHVM een interessante optie is in het arsenaal van mogelijkheden om de beste site online te zetten. Wil jij ook testen met HHVM, neem contact op met ons: [email protected].