Communauté Magento francophone

Mais oui, pourquoi au fait ?

Voici une analyse philosophico-technique d’une question existentielle qu’on se pose tous : « Pourquoi Magento est un gouffre de puissance ? »

En premier lieu, Magento dépend d’un autre framework : Zend. Et ce n’est pas le seul à être gourmand, les Ruby on Rail et autres sont aussi des affamés.

Pour revenir à Magento, c’est un framework de deuxième niveau, de l’objet d’objet. Or, revenons aux racines, à l’époque ou Stroustrup, Kernighan et Ritchie nous inventent l’objet et le C++. L’objet c’est une méthode de programmation pensée pour factoriser le code source, faciliter sa réutilisation ainsi que permettre à des humains de manipuler des concepts plus agréables que des (char *), des pointeurs et des librairies à rallonge.

Donc en gros, à partir du C, le C++ a été créé et d’autres langages ont suivi le même processus.

Mais… Car il y a (toujours) un mais, cette structuration objet est plus « lourde ». Simplifier, en général ca veut dire qu’en dessous quelqu’un a fait quelque chose de plus complexe pour vous simplifier la vie. Voyez ca comme un canard, calme en surface mais qui pédale dur en dessous. En objet c’est pareil, la simplicité pour l’humain a impliqué un code plus lourd à digérer pour la machine et puis si on fait des objets c’est bien pour développer des programmes plus utiles, complexes, effiaces etc… La programmation objet a donc une tendance naturelle à compliquer les choses pour la machine mais le compilateur, quand il est performant, réduit tout cela à un assembleur très comparable. Une même fonction en C et en C++ va fournir un code assembleur assez comparable pour que les performances soient proches. Le compilateur est plus complexe, il met plus de temps à compiler, mais l’éxécution du binaire ne sera qu’imperceptiblement plus lente, ce compilateur « gomme » donc la lourdeur engendrée par l’objet.

Résultat : c’est tout bénéfice, l’humain manipule des objets plus agréables et plus utilisables, se lance dans le fonctionnel au lieu d’avoir les mains dans le camboui (ceux qui ont fait du x86 savent de quoi je parle), la machine interprete une fois un peu plus longtemps avec son compilateur et au final, quand le programme se lance, il est aussi rapide !

Oui mais……… PHP n’est pas un langage compilé. C’est un langage interprété. Et la complexité supplémentaire pour la machine qui était gommée par le compilateur ne l’est plus. A chaque interprétation, on reprend le même code, on replonge dans les niveaux d’abstraction objets et on force le CPU a interpréter tout cela. Alors avec juste du PHP « non objet » ca allait encore. Avec du PHP 5, on attaque la notion d’objet, on s’alourdit un peu mais ca tient toujours la route. Avec Zend, c’est déjà nettement plus consommateur de ressources, on est sur une couche d’abstraction supplémentaire et ca comme à se sentir.

Alors Magento, framework de niveau 2 sur Zend qui est une surcouche de Php, là on commence à avoir du poids dans l’interprétation. D’autant plus que pendant qu’on a l’affichage, les xmlhttpdrequests (le fameux Ajax, la couche « Web 2″), présent dans Magento continue à persécuter le serveur en lui effectuant des demandes qu’il doit rendre (sans que cela soit immédiatement visible, c’est des requêtes anticipées). Le serveur sert les clients en interprétant tous les niveaux d’abstraction objets et en plus il déguste les requêtes ajax (toujours avec de l’objet) qui arrivent en parallèle des clients déjà servis !

L’objet c’est fantastique, très bien pour améliorer le fonctionnel mais sans compilation, c’est très très cher en temps CPU. APC Code cache améliore les choses en stockant du pseudo code et en améliorant les performances d’interprétation, mais ca reste indigeste. Tous les objets ne reste pas en mémoire et sont refait en permanence lors des inits des sessions, les héritages poussent à un rechargement permanent pour afficher les pages, bref… Java n’est pas un foudre de guerre non plus mais au moins en J2EE par exemple, les objets restent en mémoire après l’initialisation, ils ne sont donc pas rechargés à chaque fois.

Ceci étant ce soucis n’est pas l’apanage uniquement de Magento. Le code n’y est pas plus moche qu’ailleurs, c’est le principe de fond de faire de l’objet d’objet d’objet dans des langages interprétés qui est une des causes de la voracité en ressources de ces frameworks évolués

Alors des solutions :

- Un makefile du site Web qui fait un wget sur chaque page du site, qui le « compile » quelque part en forçant l’interprétation de chaque page et en stockant le résultat statiquement après ? Un bête crawling avec une spider maison finalement. (On l’a fait pour d’autres sites avant, ca marche pas si mal au final)

- L’optimizer Zend, qui coûte un bras, pourrait aider les choses aussi en améliorant l’interprétation, en cachant et mutualisant le pseudo code ?

- Un cache plus avancé, plus haut niveau, un cache d’objet quelque part pourrait voir le jour prochainement ?

- Le PHP se compilera il en un beau programme bas niveau un jour ?

L’objet est une belle avancée, importante fonctionnellement, elle va continuer à se répandre, dans le Web 2.0 comme ailleurs. Cependant, si nous restons dans un modèle interprété et non dans un modèle compilé alors il va falloir inventer des nouveaux ressorts pour que les performances suivent !

Bonne nouvelle, les soldes de Zadig & Voltaire sous Magento nous confirmé ce qui nous avions déjà pressentie, quand tout est bien optimisé, conçu et paramétré, Magento ca consomme mais au moins ca se scale sans problème, ca vend sans soucis, bref ca fait tourner du E-commerce dans la vraie vie ! (Ségolène, si tu lis ces lignes et que tu as le temps, tu pourrais nous faire un petit brief, un retour de ton expérience avec Magento ?) En tout cas, il faut beaucoup trimer, apprendre et observer pour tout bien ajuster en fonction de la topologie du site et des habitudes des clients du sites mais actuellement on en est sûrs, la devise de la scalabilité « More power, more users » fonctionne !

écrit par Philippe Humeau \\ tags: compilé, interprété, langage objet