Hello    
 
Je fais appel aux experts du topic PHP.    
 
J'ai récemment benché mon appli et il semblerait que PHP soit aujourd'hui mon bottleneck.
Je cherche en effet à casser les limites de mes pages, qui stagnent entrent 300ms et 600ms.
Je précise que je ne peux pas faire de cache NginX, ces pages doivent être dynamiques (une url -> plusieurs états).
Il s'agit pour beaucoup d'appels AJAX de moteur de recherche.
 
J'ai donc entrepris de me documenter sur HipHop 2 (HHVM, la fameuse machine virtuelle) qui serait 1.6x plus perf que HipHop 1 (HPHPc), lequel était déjà 3x plus perf qu'un PHP avec APC en cache d'opcode. On obtiendrait donc un gain global théorique de 4.8x.    
 
En théorie, ça a l'air easy à installer.
Mais j'aimerai bien avoir des retours là-dessus avant de mettre un pied dans un bourbier insondable.    
 
Aussi me pose-je deux questions existentielles sur HHVM :
 
Le binaire fait-il du séquentiel ou possède-t-il un moyen de paralléliser les écoutes de fichier ?
On sait que les "serveurs web" traditionnels possèdent ce type de feature, que ce soit Apache, NginX, PHP-FPM... etc.
Il serait décevant que HHVM n'ai pas ce type de mécanisme, mais la documentation ne précise pas.
Décevant dans le sens où si HHVM apporte bien un gain de 4.8 x en vitesse d'execution, il suffirait de spawner 5 threads (et plus) avec PHP-FPM pour passer devant.
Mon PHP-FPM tourne actuellement avec 30 threads, aussi c'est loin d'être une question anodine.
En pire cas, j'imagine qu'on doit pouvoir faire tourner manuellement 30 HHVM sur des ports différents et utiliser NginX comme load balancer
 
-> Réponse : Les deux mon capitaine !
hhvm --run
hhvm --daemon
Après, c'est comme tout, faut tester les perfs.

 
 
A noter, à la compilation de HHVM, Facebook recommande l'utilisation de JEMalloc en remplacement du malloc de base.
Or MySQL recommande lui l'utilisation de TCMalloc.
Après renseignements pris, les applications à threads fixes doivent utiliser JEMalloc et celles au nombre de threads variables TCMalloc.
Il serait donc plus intéressant dans le cadre d'un serveur web d'utiliser TCMalloc... à condition que son fonctionnement soit multithreadé, ce qui n'est pas évident, cf l'architecture de NginX et le fameux problème du C10k.
 

-> Jason Evans, le créateur de JEMalloc (Jason Evans Malloc) m'a répondu.
Il fait parti de la team HipHop et c'est pourquoi ils utilisent le malloc custom de Jason Evans (code-control).
Celui-ci me dit que peu importe JEMalloc ou TCMalloc, il faut au moins utiliser l'un des deux en remplacement du malloc original.

 
Le binaire est-il un PHP figé, avec des modules figés ?
Est-il possible de compiler ses propres modules (GD2, PDO, Memcached, IgBinary... etc.) ?
Je sais que c'était problématique à l'époque de HPHPc (la version C++, qui était statique).
Le binaire était un "vieux" PHP 5.2 avec une liste de modules figée car entièrement réécrite à la sauce Facebook
C'est ce qui m'avait découragé à l'époque : j'adore utiliser une distribution PHP custom avec des modules compilés et paramétrés selon mes besoins.
HHVM pourrait être une surcouche de PHP, une machine virtuelle transformant en bytecode + compilation JIT
Dans le cas où HHVM utiliserait le binaire standard PHP, on aurait aucun problème de compatibilité.  
Mais j'aimerai en être sûr...
 
-> Après un premier survol de la doc, j'ai l'impression que HHVM embarque sa propre version figée de PHP, difficilement modifiable (mais pas impossible)
Il n'y a en effet aucune référence au binaire PHP de base, que ce soit à la compilation ou dans les options de configuration du serveur.
APC est utilisé comme cache de données. Bah oui, le cache d'opcode est inutile puisque PHP est compilé !
On trouve des références Memcached, mais j'ignore encore comment ils sont utilisés (Memcached -> Session ?, ... etc.)
 
Edit : HHVM est bien destiné à remplacer le binaire de PHP, ça m'a été confirmé par l'admin de la fan page Facebook dédiée à HipHop
http://www.facebook.com/pages/HipH [...] ref=stream

 
 
Voilà la doc. Ya plus qu'à tout lire !    
 
https://github.com/facebook/hiphop- [...] untu-12.04
https://github.com/facebook/hiphop- [...] installing
https://github.com/facebook/hiphop- [...] -to-HipHop
 
https://github.com/facebook/hiphop-php/tree/master/doc
https://github.com/facebook/hiphop- [...] d.compiled
https://github.com/facebook/hiphop- [...] s.compiled
 
http://www.hiphop-php.com/wp/#p113-configuring

Tiens, ça pourrait m'intéresser cette approche pour gagner en perfs.

J'ai ajouté un lien vers la doc (bien cachée), et donné des éléments de réponse à mes questions.

slt

es tu sur d'avoir epuisé toute tes cartouches avant de te lancer la dedans ?
memcache / opcode / analyse via xdebug / xhprof des routines qui posent des problemes de perfs/ utiliser les SSI /multi curl etc ..
y a quand meme pas mal de limitation sur hiphop et ils sont bloqué sur php 5.2 non ?

Oui-oui, j'utilise déjà de l'opcode et du memcached avec toutes les options possibles (compression, igbinary...), et du cache nginX. Le truc c'est que mes appels AJAX ne doivent pas être cachés, il me faut du contenu frais. Et donc du PHP.
 
De ce que j'ai compris, les limitations sur HipHop semblent faibles (pas de eval et PHP 5.2 c'est pas la mort, sauf si tu codes avec une usine à gaz telle que Symfony).
 
Là je suis pas loin de le compiler, il me manque juste un GCC 4.6 (pas 4.5 ni 4.7, mais bien 4.6) que je dois installer sur ma Debian. Faut que je trouve le temps de me remettre dedans, et ensuite de faire des tests avec le fichier de configuration pour bien comprendre comment mettre les sessions en memcached (le fichier de conf HipHop est assez différent du php.ini).

ah tu bloque sur la compilation toi aussi !
de memoire j'etait a 19% sur la derniere etape et il semblait y avoir un probleme sur la version gcc ( on doit suivre lesmeme flux )
comment tu compte l'installer ? en utilisant les backports ?
 
pour php 5.2 c'est qu'il va bientot devenir plus maintenu en terme de sécu, et sinon, peut etre que nodejs peut etre utilisé en complement de ton infra existante, voir mongodb localisé sur certaines partie live
 
en tout cas, fait nous partager ton feedback si tu fais de la prod avec hhvm