HipHop, compilateur PHP et bottleneck PHP

Les développeurs de Facebook ont mis au point HipHop for PHP. Pas si loin du compilateur PHP tel que Roadsand ou phc, HipHop réalise une traduction du code source PHP en C++ et se charge de le compiler en embarquant un serveur HTTP léger.

Alors on entend tout et rien à son sujet, alors mettons quelques éléments de compréhension sur la table.

Optimiser son application / son site est un domaine en soi. On peut mettre en cache les résultats des appels aux bases de données (via la base elle-même ou un autre moyen), mettre en cache des parties ou des pages entières générées… Memcached sera votre ami dans bien des cas. Je ne parle même pas d’une utilisation optimale de plusieurs serveurs HTTP (un pour les données statiques, un autre pour les scripts).

Enfin bref, on arrive vite à une limite, un appel où tout est en cache. Et quand on veut améliorer les performances, il faut se tourner du côté de PHP.

Il est déjà important de savoir comment fonctionne PHP. Quand on appelle un script, il est parsé, puis traduit en opcode lequel opcode est ensuite lancé dans une machine virtuelle qui fera le reste du boulot (traduction en instructions CPU et exécution). Ceci à chaque fois.

On peut évidemment optimiser un peu ça. Il y a principalement les caches d’opcode (APC, eAccelerator…). Mais on arrive vite à une autre limite, la machine virtuelle prendra bien un opcode caché, mais elle refera éternellement le même boulot.

L’idée est alors de compiler le PHP. Passons sur phc qui semble inactif.

On a d’un côté Roadsand, qui proposent une autre implémentation de PHP et qui vont effectivement traduire votre script en instructions binaires pour le CPU (bref compiler). Et de l’autre on a HipHop qui va traduire votre script PHP en C++, puis le compiler. Pourquoi j’ai séparé les deux ? Ils arrivent au même résultat. Mais par des moyens différents. On a un binaire. Selon les possibilités, il intègre son serveur HTTP, ou bien il dialogue via FastCGI avec un serveur HTTP.

Roadsend permet du runtime eval (eval, include), HipHop non et le sacrifie fièrement. On va pas rentrer dans les détails inutiles ici.

Je passe aussi l’optimisation au sens propre du code : profilage, blablabla et tout et tout. Ça se fait très bien et permet de voir des défauts d’architecture.

Bref, voyons ce qui nous a amené ici : l’optimisation, compiler PHP et les diverses conneries entendues. Ne retenons qu’une seule chose entendue, qui n’est pas foncièrement une connerie et qui mérite nuance et explication. Les conneries, elles, elles resteront.

Lu chez Maxime Valette :

Avant d’en arriver au stade d’avoir besoin de compiler du PHP transformé en C++, il faudrait déjà penser à s’affranchir de son framework qui ne peut que ralentir l’exécution de son site.

Bon, un framework, pourquoi ? Si Yahoo a choisi Symfony, c’est pour une bonne raison : le développement. Ils savaient très bien que c’est une surcharge de PHP. Mais un développement en équipe, agile, reposant sur des briques découplables, testable est plus qu’un confort. C’est générique. mais c’est un gain d’argent. Un développeur coûte cher. Les serveurs, c’est pas cher. Seule la bande passante est chère. (comparativement)

Il y a des cas où le service est relativement simple, avec une évolution limitée des fonctionnalités. Dans ce cas, oui, faites sans framework. Il ne sert à rien de sortir le marteau pilon pour écraser la mouche. Vous pouvez, mais ne râlez pas à propos de performance sur la lourdeur du framework. Vous avez fait un choix, celui de penser aux capacités de développement avant tout. Si vous voulez, vous pouvez créer votre propre framework, adapté à votre utilisation, pour combiner le meilleur des deux. Mais quand vous aurez tout optimisé, système de cache et tout et tout, alors PHP sera votre facteur limitant, du fait de votre framework. The bottleneck.

Bon, c’est assez tranché, mais tout ça pour vous dire que le PHP peut devenir le facteur limitant. Parce que déjà, si quelque chose est en cache, il faut bien à un moment ou à un autre l’y mettre. Et puis quand tout sort de cache, il y a quand même du code qui s’exécute.

Pas convaincu ? Essayez de générer un fichier PDF à l’aide de FPDF. Pas le truc de Mickey, un gros PDF, pleins de pages. Par exemple, 5000 bons de commandes en un seul PDF. Vous allez le sentir le bottleneck, vous allez sentir du PHP pur qui tourne. Récupérer les infos de la base de donnée c’est du gâteau à côté (c’est peut-être même déjà en cache ?). Les appels d’appels de re-appels de fonctions, de méthodes, d’objets… c’est élégant, mais ça a un coût.

Donc, compiler PHP peut-être une porte à ouvrir, si on veut gagner en terme de performance. Facebook en était là. Et c’est tant mieux, ça complète la voie.