Récemment Facebook a officiellement dévoilé qu’ils avaient travaillé un compileur de code PHP qui améliorerait grandement les performances des sites. Je me base sur les 2 sources officielles de Facebook pour vous faire le résumé de en quoi ça impacte les développeurs Web.

• Le post du lead developer
• La vidéo de présentation

Si vous avez d’autres sources, l’avez compilé vous même et testé, partagez dans les commentaires ou discutez en avec moi, je mettrais à jour ce post au fur et à mesure.

Background

Commencé il y a 2 ans comme une « proof of concept » dans un hack day interne à Facebook, le lead developer a écrit de quoi transformer du code source PHP en code C++, lui même compilé grâce à g++. Pour facebook on obtient par exemple un exécutable d’1Go.

L’objectif était bien sur les performances d’exécution. 18 mois pleins de développement à 3 ingés et 300000 lignes de code plus tard, ils ont passé les 6 derniers mois à déployer ce nouvel interpréteur sur les clusters de Facebook (4 datacenters de 800 machines).

Cela signifie qu’il est validé en production sur l’un des plus gros trafics au monde, sur une base de code qui doit être franchement conséquente (300 ingés facebook, ça doit faire une sacrée équipe juste pour la partie PHP). Mais cela signifie aussi qu’il n’est validé que pour une unique configuration.

Performances

Une première rumeur parlait de 80% de CPU économisé, dans la vidéo on parle plutôt de 50% de CPU pour les pages Web et de 30% pour l’API facebook, comparé à PHP 5.2 avec APC, sur Apache 1.3.

D’où vient la différence entre site et API ? ce n’est pas dit, mais j’imagine que le site doit beaucoup jouer avec des chaînes de caractères pour générer le HTML et qu’il requiérait donc à l’origine beaucoup plus de processeur qu’une API qui se contente de récupérer et renvoyer des données.

Cela ne signifie pas forcément que le HTML sera fabriqué 50% plus vite, mais que si vos serveurs frontaux sont le point bloqueur en période de charge, ils pourraient tenir 2 fois plus de sessions. Cela dit, les premiers points bloqueurs en période de charge sont en général l’accès disque, la base et le réseau.

En tout cas, 50% de CPU en moins qu’un site avec APC, ça fait entrer HipHop for PHP dans les solutions à considérer sérieusement, alors voyons quels sont les problèmes connus.

Limites

Pas de support d’apache

HipHop for PHP embarque son propre serveur Web et n’a donc plus besoin d’Apache. Ce seul point peut être bloqueur pour la plupart des sites déjà déployés et qui ont passé du temps à configurer Apache. Mais d’après certains, se débarrasser d’Apache serait le premier pas vers un très haut niveau de performances.

PHP 5.2 uniquement

Ils n’ont travaillé que sur cette version puisque c’était la leur. Passer d’une version antérieure à celle ci n’est pas très difficile, mais ceux qui sont déjà en PHP5.3 ne vont pas downgrader

Language

En touchant directement à l’interpréteur PHP, l’équipe a fait quelques choix radicaux :

• plus de eval(). « eval is evil » comme le savent bien les développeurs Web, et effectivement on ne l’utilise pour ainsi dire jamais. Mais il suffit d’un cas spécifique ou d’une seule librairie qui l’utilise pour que le site ne soit pas compatible avec HipHop. Certains moteurs de templates l’utilisent par exemple.
• plus de create_function(). Là encore les cas sont extrêmement rares, mais même commentaire que pour eval() : faites une recherche dans votre code source et vous pouvez être surpris
• preg_replace et /e : je n’en avais jamais entendu parler mais le modifier ‘e’ sert à lancer un eval() dans la string modifée
• Plus vicieux car moins facile à trouver : certaines portions de code qui font des tests sur la définition d’une classe ou d’une fonction ne marcheront plus car on passe d’un language interprété à un language compilé, où partout dans le code toutes les classes/fonctions sont censées déjà exister. Par exemple :

  if(function_exists('foo')) {
  code here
  }
  function foo() {
  }

se comportera différemment … Pas plus de précisions pour l’instant, ce dernier point est très génant car ce genre de test est courant dans le framework Zend ou PEAR.

Et ce ne sont que les points notés par l’équipe de Facebook, même si on se doute que la base de code FB est très large et doit couvrir 95% des cas, il y a toujours un risque si votre projet utilise quelque chose de spécifique.

Extensions

HipHop for PHP est multithread et il semble que certaines extensions ne le supportent pas. Ils ont donc du en corriger certaines pour pouvoir les utiliser, ce qui n’est pas souhaitable pour le site moyen, pour des raisons de compétences (peu de développeurs PHP ont fait du C) et de coût de maintenance (à chaque upgrade de l’extension, il faudra repatcher)

Futur

Facebook veut jouer le jeu de l’open-source et contribuer à PHP (comme ils l’ont déjà fait par ailleurs), la roadmap est donc :

• être compatible avec Apache (en espérant qu’ils ne se focalisent pas sur leur version d’apache qui est la 1.3)
• passer à PHP 5.3 (donc tant pis pour les versions antérieures à la 5.2)

Il va surtout falloir attendre les retours de la communauté pour connaître les autres limites de ce nouveau compiler en dehors de l’architecture FB. Si vous avez d’autres liens, analyses ou si vous avez tenté une implémentation, on attend vos retours dans les commentaires.

Autres ressources :

• groupe de discussion officiel
• le wiki sur gitHub ainsi que les sources
• le résumé vu par techcrunch, par RWW
• des commentaires beaucoup plus nuancés que la presse non technique :
  • rappel des limites
  • rappel de ceux que cela concerne vraiment
  • Rasmus Lerdof (le créateur de PHP) lui même
• comment ça marche, en français
• EDIT 25/02/10 : une comparaison avec des solutions déjà existantes : la conclusion est que HipHop est effectivement performant mais cette première version ne sera pas simple à installer pour tout le monde

Utilisez RSS pour une analyse quotidienne de l’actualité du développement d’applications web OU
Suivez ce compte Twitter pour une revue de presse en quasi temps réel (disponible aussi en RSS)