Facebook PHP compiler (HipHop PHP) : les limites

ce site a migré : retrouvez cet article à jour sur braincracking.org

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)

Comments

[Rédigé par : Yoan]

g++ n'est rien d'autre que gcc.

[Rédigé par : jpvincent]

merci de la précision :)

[Rédigé par : Maximegarcia]

Ton analyse sur les limites sont intéressantes. Je suis entièrement d'accord avec toi. Je rajouterais, dans le même style qu'eval, les includes dynamiques, les autoloads et j'en passe.

Une question que je me pose sur la compatibilité future avec php 5.3, c'est dans l'objet. Ya des éléments statiques qui sont résolus à l'exécution, d'autres à la compilation... Ça va pas être simple...

Ça ouvre une porte intéressante. Et une conciliation entre le confort de dév du langage interprété et la puissance brute du langage compilé.

Pour ma part je me suis atteler à essayer d'expliquer au néophyte le pourquoi du comment ils en sont arrivés là. c'est un vaste sujet, mais ça peut dégrossir :
http://www.maximegarcia.fr/blog/2010/02/hiphop-compilateur-php-et-bottleneck-php/

[Rédigé par : jpvincent]

@maximegarcia : intéressant ton lien, notamment pour rappeller quelles sont les alternatives de la solution retenue par FB (alternatives qu'ils ont testé et rejetées, mais peu de boites ont les problèmatiques de FB)

concernant PHP5.3 et le passage d'un language interprété à un language compilé, ils ont bien dit durant la présentation que c'était ce qui leur avait pris le + de temps, et pour 5.3 ça sera pire, raison pour laquelle à mon avis ils le donnent à la communauté open-source.

Là aussi tout ce qu'on peut attendre, c'est une liste + précise des incompatibilités que cela va engendrer.

[Rédigé par : Geritsaurelien]

Très intéressant, j'aimerai en savoir d'avantage sur le sujet d'optimisation.
Facebook à fais un excellent travail et il me tarde de tester, mais en terme d'utilisation une base en c++ sera surement obligatoire pour une installation ?
Je cherche à optimiser au maximum un serveur tournant avec php et il est vrai que APC ne me satisfais pas, j'ai également tester memcache , bref une vrai solution pour gagner en performance est une véritable recherche du monde perdu :D
Pour ce qui est de l'incompatibilité avec php5.3 je n'ai pas encore fais le pas (suis tjrs en 5.2.12)

[Rédigé par : jpvincent]

à priori, rien à faire du côté de la base, le gros EXE généré continue à se comporter comme un couple Apache/PHP presque normal.
Si le CPU est vraiment ce qui te ralentit, la solution peut être intéressante une fois qu'on est sur que la compatibilité avec l'existant est OK, mais au moment où je l'écris, le code source n'est pas dispo donc personne n'a pu le tester en dehors de l'environnement FB

[Rédigé par : metagoto]

En fait d'après facebook, l'économie en cycle CPU pour l'API est de 30%... en servant 2 fois plus de requêtes.

La perspective de pouvoir générer des binaires (sans server, juste en CLI) à partir de codes php, je trouve ça très intéressant. Reste à voir comment ça se passe vraiment, mais bon, d'après les infos divulguées, je sens que certains de mes scripts shell vont se retrouver compilés avant même qu'ils aient compris ce qu'il leur arrive ;)

Moi ce qui m'emballe le plus dans tout ça c'est le framework qu'ils ont mis au point. La possibilité de faire des "extensions" pour hiphop. Imaginons que hiphop soit aussi cool que ce qui est annoncé (toutes proportions gardées), alors il "risque" d'y avoir toute une activité parallèle à l'instar de ce que propose PECL. A terme, ce sont par exemple des apps desktop (si par hazard ça intéresse encore quelqu'un) qui pourraient voir le jour, ou n'importe quoi d'autre qui est à mille lieux de l'usage conventionnel de php.

[Rédigé par : jpvincent]

pour un site web classique où les "bottlenecks" se trouvent en général ailleurs que dans le CPU du serveur, l'intérêt est moindre, mais ça peut faire partie de l'arsenal des développeurs.

par contre il est clair pour moi qu'une fois que ça sera un peu testé et debugué par la communauté, je tenterais l'aventure sur mes serveurs de worfklow qui s'occupent des traitements lourds en parallèle du site, comme le traitement des images ou des logs, dont la vitesse d'exécution dépend en premier lieu du CPU

[Rédigé par : Account Deleted]

"HipHop for PHP embarque sont propre serveur Web" *son

[Rédigé par : Account Deleted]

"toutes les classes/fonctions sont censé " *censées

[Rédigé par : jpvincent]

corrigé, merci