Bench PHP 5.2 vs PHP 5.3

le - Lien permanent 12 commentaires

Avec la sortie de PHP 5.3 et l’apparition de nouvelles fonctionnalités, une question est fréquemment posée : qu’est-ce que vaut PHP 5.3 au niveau des performances ? Est-ce que toutes ces nouveautés ne vont pas avoir d’impact négatif ?[1]

Voila plus d’un an que PHP 5.3 est annoncée comme plus rapide que PHP 5.2 (Cf ce post sur internals@, par exemple) ; j’avais moi-même effectué quelques benchmarks synthétiques, dont j’avais posté les résultats en novembre dernier.

Mais ces tests, qui montraient un gain de performance de 10 à 20% pour PHP 5.3 par rapport à PHP 5.2, n’avaient pas été joués avec la version finale de PHP 5.3.0, d’une part, et ne testaient que des fonctions internes de PHP — pas une véritable application.

Voici donc quelques résultats obtenus avec des « vraies » applications, comportant de nombreux fichiers, des appels à une Base de Données, …
… En somme, des applications du genre de celles que nous sommes susceptibles d’utiliser tous les jours sur nos serveurs !

Sommaire de cet article :


Méthodologie

Si vous voulez aller directement aux résultats

Logiciels testés

J’ai effectué mes tests avec trois logiciels, en installation « de base », sans ajouter de plugin ni quoi que ce soit :


Versions de PHP testées

Pour ces tests, j’ai utilisé deux versions de PHP, toutes deux compilées par moi-même, avec les mêmes options de configuration.
Ces deux versions de PHP sont chargées en tant que module Apache, via deux instances différentes d’Apache[2] :

  • PHP 5.2.9, avec Apache écoutant sur les ports 529**
  • Et PHP 5.3.0, avec Apache écoutant sur les ports 530**

Les options de compilation et de configuration ne sont certainement pas optimales : à peu de chose près, j’ai conservé toutes les valeurs par défaut ; mais, considérant que je n’ai tunné ni la première installation, ni la seconde, la comparaison devrait ne pas être « trop faussée ».

Les sorties de phpinfo() sont disponibles ici, si vous voulez en savoir plus :

(Ces sorties de phpinfo() ont été enregistrées alors que j’avais activé l’extension APC)


Deux séries de tests

Les trois applications ont été testées une première fois sans que l’extension APC ne soit activée.

Les mêmes tests ont ensuite été rejoués avec l’extension APC activée.


Méthodologie

Les trois applications ont été testées en utilisant l’outil ab, avec les options suivantes, qui me semblent raisonnables pour ma machine de tests :

  • concurrence = 10
  • nombre d’occurrences = 1000

Le test est lancé une première fois sur l’instance en PHP 5.2.9, puis sur l’instance en PHP 5.3.0.
Ceci est répété 10 fois de suite (on a donc un test sur PHP 5.2.9, puis un test sur 5.3.0, puis un test sur 5.2.9, puis sur 5.3.0, etc…)

J’ai ensuite calculé la moyenne des 10 séries de test pour PHP 5.2.9 et pour PHP 5.3.0 ; c’est cette moyenne qui me sert de résultat pour comparer les deux versions.

Et voici quelques éléments de la machine de tests :

  • CPU Core 2 Quad 9550 ; les quatre cœurs étaient utilisés à 100% pendant l’exécution des tests
  • 6 GB de RAM ; Il restait en permanence de la RAM libre pendant l’exécution des tests
  • Les binaires d’Apache, PHP, et les scripts testés sont sur un disque dur 10k rpm
  • Et l’OS est un Linux Ubuntu 64 bits.


Résultats obtenus sans APC

Pour commencer, voici les résultats obtenus pour chacun des trois logiciels testés, sans APC :

Wordpress

  • PHP 5.2.9 : 33.26 requêtes / seconde
  • PHP 5.3.0 : 41.54 requêtes / seconde
  • Différence : 124.91 %

php-5.2-vs-php-5.3-wordpress-1.png

Pour ce graphique, comme pour tous les autres présentés dans cet article, plus la barre correspondant à une version de PHP est haute, plus cette version de PHP est capable de répondre à un nombre élevé de requêtes par seconde — mieux c’est niveau performances, donc.

Drupal

  • PHP 5.2.9 : 51.33 requêtes / seconde
  • PHP 5.3.0 : 63.58 requêtes / seconde
  • Différence : 123.87 %

php-5.2-vs-php-5.3-drupal-1.png

Quickstart Zend Framework

  • PHP 5.2.9 : 77.28 requêtes / seconde
  • PHP 5.3.0 : 97.79 requêtes / seconde
  • Différence : 126.54 %

php-5.2-vs-php-5.3-zf-quickstart-1.png


Résultats obtenus avec APC

Et maintenant, les résultats des mêmes tests, en ayant activé l’extension APC (aucune option de configuration n’a été définie dans le fichier php.ini ; toutes les valeurs de configuration sont donc celles par défaut — même si ce n’est pas optimal).

Wordpress

  • PHP 5.2.9 : 128.66 requêtes / seconde
  • PHP 5.3.0 : 139.38 requêtes / seconde
  • Différence : 108.33 %

php-5.2-vs-php-5.3-wordpress-apc-1.png

Drupal

  • PHP 5.2.9 : 207.79 requêtes / seconde
  • PHP 5.3.0 : 212.84 requêtes / seconde
  • Différence : 102.43 %

php-5.2-vs-php-5.3-drupal-apc-1.png

Quickstart Zend Framework

  • PHP 5.2.9 : 297.87 requêtes / seconde
  • PHP 5.3.0 : 290.91 requêtes / seconde
  • Différence : 97.66 %

php-5.2-vs-php-5.3-zf-quickstart-apc-1.png


Conclusion

Pour conclure, voici quelques mots — sans trop réfléchir non plus : c’est aussi à vous d’interprêter ces résultats et de voir en quoi est-ce qu’ils peuvent être intéressants dans votre situation !

PHP 5.3 : gain de performances !

Comme conclusion, je ferai volontairement simple : sur ces quelques tests d’applications « réelles », sur une installation PHP « standard », PHP 5.3.0 s’en sort nettement mieux que PHP 5.2.x : environ 25 % de requêtes par seconde supplémentaires !

Une fois l’extension APC activée, le gain est nettement moins visible : seulement quelques pourcents, voire même une légère perte dans un cas :-(
Cela dit, on voit encore une fois l’intérêt d’activer APC, à partir du moment où vous êtes libre d’installer des extensions sur votre hébergement : sur ces tests, un très rapide calcul montre que vous répondez à environ trois fois plus de requêtes par seconde avec APC que sans !

A quoi est dû ce gain ? Je n’entrerai pas dans les détails[3], mais il y a fort à parier que les quelques optimisations citées ici n’y sont pas pour rien :

  • Déplacement des constantes vers des zones mémoire en lecture-seule
  • Amélioration du gestionnaire d’exceptions : il est maintenant plus simple, et tient sur moins de code.
  • Suppression d’appels système à « fopen » pour les inclusions de fichiers via require_once et include_once, résultant en une amélioration de la rapidité de ces deux directives.
  • Refactoring de la pile d’appels
  • Utilisation de gcc4 pour la compilation.

Pour plus d’informations, n’hésitez pas à consulter le changelog de PHP 5.3.0.


Quel intérêt ?

J’en entends déjà certains se demander Mais quel intérêt pour mon application ? Et quid du coût probable de migration de PHP 5.2 vers 5.3 ?

Et bien, pour votre application toute seule, l’intérêt, c’est vous le mieux placé pour le déterminer ; mais pensez à ceci : 20% de gain CPU, si vous avez 10 serveurs faisant tourner du PHP, ça peut signifier que deux de ces serveurs pourraient être utilisés pour autre chose… A vous de voir l’économie que cela peut signifier[4] ;-)

Après, oui, rendre votre application compatible PHP 5.3, et la re-tester, peut prendre du temps, et représenter un coût non négligeable — mais pour les futures applications que vous allez développer, qu’en est-il ? Pourquoi ne pas partir sur PHP 5.3 dès la phase de développement ?


Disclaimer

A noter tout de même : de manière générale, un serveur faisant tourner PHP aura aussi tendance à servir des fichiers statiques (JS, CSS, images, …), ce qui peut avoir un impact sur sa charge, indépendamment de PHP — et les tests présentés ici ne prennaient en compte que le chargement de la page PHP.

A noter aussi : les tests réalisés ici ne testaient qu’une seule page de chaque application, et non chaque application dans sa globalité. Avant de vous lancer dans une — possiblement coûteuse — migration compléte d’application, il peut être intéressant de jouer des tests un peu plus approfondis !


Aller plus loin ? D’autres tests ?

Si vous effectuez d’autres benchmarks de ce type, ou plus poussés, je suis extrêmement intéressé ! N’hésitez pas à laisser un commentaire ;-)

En attendant, vous pouvez jeter un coup d’oeil sur ces deux benchmarks d’eZPublish, effectués il y a quelques semaines :

Les gains de performance constatés sont du même type que ceux que j’obtiens dans cet article ; et ce, que ce soit sous Linux ou sous Windows, ce qui est une excellente nouvelle !


Au passage, vous trouverez joint à cet article le fichier .ods que j’ai contruit, regroupant tous les résultats obtenus (et pas seulement les moyennes présentées ici).


Notes

[1] D’aucun diraient que ça fait deux questions, et pas une ; mais elles sont liées, donc bon…

[2] Il faudrait, un jour, que je rédige un article expliquant comment installer plusieurs versions de PHP sur une seule machine, d’ailleurs… ça fait plus d’un an que j’ai les notes nécessaires… il faut “juste” que je trouve le temps de rédiger…

[3] Détails que je ne connais pas en détails, d’ailleurs ^^

[4] OK, si vous en arrivez à calculer quelles économies vous pourriez réaliser de cette manière, changer de version de PHP n’est pas la seule chose à laquelle vous penserez : passer à un autre serveur (nginx, par exemple), ou installer un reverse proxy (varnish, par exemple) peuvent être deux bonnes idées)

Vous avez apprécié cet article ? Faites le savoir !

Commentaires

1. Par Adrien M. le 2009-07-20 08:39
Adrien M.

Merci d'avoir pris le temps de benchmarker les 2 versions. Des articles excellents, comme très souvent sur ton blog !!

On en redemande :)

2. Par CERDAN Yohann le 2009-07-20 09:03
CERDAN Yohann

Merci beaucoup pour cette article très intéressant (comme d'habitude).

C'est que j'en ressort : l'intérêt du passage en 5.3 pour un non-développeur c'est clairement les performances améliorées. L'inconvénient, le respect des normes 5.3 des anciennes applications.

3. Par cyruss le 2009-07-20 15:38
cyruss

Super, merci pour les retours.
Pour les benchs moi j'utilise http_load ou siege (joedog) qui sont un peu plus complets que ab.

++

cyruss

4. Par flan le 2009-07-20 17:47
flan

Sympa les benchmarks :) Surtout que ce n'est pas toujours facile d'en trouver ;)

(mais tu peux tout de même enlever 100 à chaque différence ^^)

5. Par Pascal MARTIN le 2009-07-20 21:53
Pascal MARTIN

Merci à tous :-)

Yohann > Pour un non-développeur, effectivement, les performances peuvent être un sacré plus. Après, heureusement, pour un développeur, ce n'est carrément pas le plus important ; au contraire, je suis plus attiré par le lot de nouvelles fonctionnalités de PHP 5.3 que pour 20% de rapidité en plus (ça, c'est plus à mon hébergeur / client de se soucier du nombre de machines qu'il veut bien mettre ; quelques millisesondes de différence sur le temps de génération de la page ne changera globalement rien pour l'utilisateur final, et encore moins pour moi, alors que certaines des nouveautés de PHP 5.3 me simplifieront la vie, en tant que développeur).
Disons que les performances sont un argument "chiffré" pour nos clients -- et ça fait toujours plus d'effet qu'un "mais si y'a cette fonctionnalité de la mort qui tue", quand on parle à un non-technicien ;-)

cyruss > Je ne connais pas http_load (faudra que je jette un oeil) ; ce que j'aime avec siege (même si je ne l'ai pas encore souvent utilisé), c'est la possibilité de bencher toute une série d'URL (pour, genre, le script PHP + les CSS/JS/images) -- et la possibilité d'utiliser un proxy pour obtenir cette liste d'URLs ^^

flan > (ah tiens, vous, ici ? ^^ ) Tu me connais, les maths et moi :-(
mais ce qui compte, c'est surtout les écarts entre les chiffres ^^

6. Par pierre le 2009-07-23 09:47
pierre

A quoi correspond le pourcenatage :

   * PHP 5.2.9 : 51.33 requêtes / seconde
   * PHP 5.3.0 : 63.58 requêtes / seconde
   * Différence : 123.87 %

Car de 51.33 à 63.58 ca fait pas 123.87 % (100% de différence signifierait du simple au double)

7. Par Pascal MARTIN le 2009-07-23 19:31
Pascal MARTIN

Heu... j'ai peut-être quelque peu fait n'importe quoi dans mon calcul ^^ (je ne sais jamais dans quel sens ça marche ^^ Cf le commentaire de Flan, d'ailleurs ^^ )

C'est d'ailleurs aussi pour ça que j'ai pris soin de donner, avant tout, les nombres de requêtes par seconde.

8. Par pop's le 2009-08-20 15:15
pop's

Hello pascal,

quelques millisesondes de différence sur le temps de génération de la page ne changera globalement rien pour l'utilisateur final, et encore moins pour mo

pour info ci google rajoute 500ms au temps de génération de la page de résultat de recherche c'est 20% de recherche en moins donc oui sur une gros audience on compte bcp au ms lol

je bosse pour un site qui fait 70 000 visiteur unique par jours et 700 000 pages vue par jours, on a du faire bcp d'optimisation apc/memcached et aussi config. serveur (les bon header pour gérer les caches navigateur et le gzip) enfin voila c'est sur que pour un petit site 20% de perf. c'est pas trés utile.

9. Par moulinette le 2009-08-22 07:18
moulinette

Voyez les benchmarks Apache/PHP sur ce site :

http://trustleap.ch/en_scalability.html

A suivre: il semble qu'ils veuillent faire un traducteur pour PHP...

10. Par Pascal MARTIN le 2009-08-26 21:13
Pascal MARTIN

@pop's > certes, pour un gros site, 20%, ça représente pas mal : sur 10 serveurs (un site pas trop mal déjà, sans être google non plus), ça fait une sacré économie ^^

Après, les 500 ms de chargement de page de google, c'est tout compris, il me semble ? génération du HTML, plus téléchargement des JS/CSS/images ? Si oui, quand on voit certains sites à plus de 15 secondes de chargement de page (dont seulement deux secondes de PHP)... on se dit qu'il y a bien plus à gagner avec un brin d'optimisation Front End qu'avec des optimisations Back End...

... Même si je suis conscient de l'importance des optimisations côté PHP / DB / Serveur -- et que j'apprécie particulièrement quand on me donne du temps pour bosser là-dessus ;-)

11. Par Sam le 2009-11-15 10:46
Sam

Merci pour cette article. Ya t'il une raison particulière pour n'avoir testé qu'avec APC et pas avec eAccelerator ( moi j'obtiens généralement de meilleur performances avec ce denier )

12. Par Pascal MARTIN le 2009-11-20 06:44
Pascal MARTIN

Bonjour,

Non, pas de raison particulière, hormis le fait que j'aie l'habitude de travailler avec APC, alors que je ne connais pas vraiment eAccelerator ; le premier est pour ainsi dire devenu un "réflexe" (vu de loin, eAccelerator ne semble pas mis à jour bien souvent, ce qui n'est pas encourageant, devrais-je ajouter).

Considérant que, ici, l'objectif était de tester avec et sans un cache d'opcode, les différences entre ceux-ci ne me semblaient pas capitales -- mais je ferais bien quelques tests, un jour... Qui sait ^^

Ce post n'est pas ouvert aux nouveaux commentaires (probablement parce qu'il a été publié il y a longtemps).