fév 05

Durant nos différents échanges à Bargento, j’ai réévoqué la piste d’un « compilateur de site ».

C’est un projet qui peut prendre de multiples formes, du préloading d’un site pour rendre le cache du reverse proxy efficace immédiatemment ou encore appeler tous les liens avec une spider et sortir un site « Semi statique » à partir du site Dynamique originel.

Plusieurs personnes ont trouvé l’idée intéressantes, certains ont même déjà de l’expérience dans le domaine, un contributeur Drupal, l’admin du vendée Glob (de AFG je crois ?) un monsieur de chez Smile. Je n’ai pas retenu tous les noms ou toutes les bonnes volontées mais je suis prêt à créer un groupe de travail sur ce point avec les volontaires.

L’idée est la suivante :
Les langages interprétés comme PHP ne sont pas très optimisés pour les processeurs et leurs systèmes de cache.
Ce point peut se compenser en imaginant un site Web très dynamique (Zend/Magento par exemple) comme un « code source » de l’époque C++. Le but c’est que la version dynamique reste bien LA référence mais que pour des raisons de performances, ont « pré calcul », on compile, une partie des pages du site. Du coup, le serveur Web fournit des pages HTML et non plus du PHP qui génère du HTML. Le rapport de puissance peut aller de 1 à 10 sans problème, comprenez qu’un même serveur Web frontal pourrait servir 10000 connexions simultanées au lieu de 1000.

Outre le gain de performances et l’économie de puissance, on constate également que le surfer reçoit une information quasi immédiatemment puisque le serveur n’a plus à générer du HTML puis à l’acheminer mais juste à l’acheminer.

Les limites :
En premier lieu, ceci ne permet d’optimiser que les performances des serveurs Web. En effet, ce qui est allégé, c’est le temps de rendu des pages et uniquement ce point. Rechercher un produit dans une base de données pas optimisée n’ira pas plus vite qu’avant. En poussant le vice, on pourrait précalculer les réponses aux 3 recherches les plus fréquentes dans le moteur selon une espèce de règle des 80/20.

Ensuite, il ne faut pas oublier que le site doit être généré à une fréquence suffisamment élevée pour que les changements importants soient visibles rapidement. Il faut également le « compiler » sur un autre serveur que celui de production car sinon on va entacher ses performances lors de la génération des pages semi-statiques. En fait il faudrait même pouvoir recompiler le site à la demande, sur tout ou partie (les prix uniquement, les articles et les prix, juste une page, comme avec un Makefile en fait)

Les obstacles :
La complexité du projet réside dans le fait que de nombreux élements nécessitent l’affichage d’informations dynamiques. Le caddie d’une personne, ses « choix pour plus tard », les comparateurs de prix ou de produits etc… De même, interroger la base de données en faisant une recherche sur un site répondra forcément un contenu différent selon la recherche (sinon on risque de décevoir un peu le visiteur).

On ne peut pas non plus trop déporter le processus dynamique sur le poste client, cela peut dans certains cas engendrer des risques de sécurité. La business logic de traitement des commandes et ce genre de choses ne peut pas résider « customer side » dans la machine virtuelle javascript du browser sinon elle est aisée à corrompre.

Mais c’est un peu comme dans la pub pour une certaine carte de crédit :
« Il a ce que vous ne pouvez pas rendre statique, pour tout le reste, précompiler votre site ! »

Alors ? Faisable ou pas ? Utile ou juste une idée en l’air ? J’en appel aux volontaires pour qu’on voit si un petit groupe de travail souhaite se pencher efficacement dessus.

écrit par Philippe Humeau \\ tags: , , ,


7 commentaires sur “Vers un compilateur de site ?”

  1. 1. Frédéric Dit :

    Entre l’interpretation PHP et le reverse proxy, il y a plusieurs d’intermédiaires. Il y a par exemple la compilation PHP avec Roadsend (google it!).

    Le problème de faire travailler le CPU du client (via AJAX), c’est qu’au niveau référencement, c’est pas top non plus. Après, ça dépend quelles informations on souhaite afficher. Certaines données sont inutiles au référencement mais, très utiles à l’utilisateur (son panier, par exemple).

    Pour la sécu, il est toujours possible d’utiliser les fonctions de cryptage de javascript, mais je pense que tu peux nous éclairer un peu plus sur la faisabilité de ces choses Philippe.

  2. 2. Alexandre Dit :

    sinon,il y a le reverse proxy varnish, qui supporte les include tags esi

    http://varnish.projects.linpro.no/wiki/ESIfeatures

    ca permet en gros, si le site web est developpé pour bien sur, de cacher en statique certaines parties du site, et d’autres non.

    le reverse proxy s’occupe de faire le rendu final,en faisant des includes (via des get http), des différentes parties d’une page.

  3. 3. Frédéric de Gombert (le monsieur de Smile) Dit :

    Je te confirme l’immense intérêt que nous portons à ce sujet chez Smile!

    La question de la publication statique est un sujet récurent lorsque l’on traite des sites visant de très hautes performances et, comme tu le soulignes, ça donne des résultats totalement imbattables!

    Nous avons déjà développé pour eZpublish (un CMS open-source) une extension de publication « fragmentaire » fonctionnant selon le mécanisme suivant:
    - les pages sont découpées en blocs. La subtilité, c’est que chaque bloc est accessible via une URL
    - ces blocs sont agrégés pour former la page finale envoyées à l’utilisateur

    Techniquement dans la publication statique:
    - les blocs sont générées sous formes de fichiers HTML
    - les blocs sont assemblés par les frontaux grâce à Apache SSI (Server Side Include)

    Je pense qu’il ne devrait pas être très compliqué de reproduire ce genre de mécanisme dans Magento.

    Après, on pense déjà à plusieurs pistes d’amélioration ou d’évolution dont nous pourrions discuter ensemble. Par exemple:
    - utilisation de ESI (Edge Side Include): permet à un reverse proxy de faire du cache par bloc (plutôt que par page)
    - utilisation de proxy-cache derrière le SSI, afin d’éviter de générer des fichiers

    En résumé, c’est un sujet sur lequel nous serons de toute façon amenés à réfléchir dans le cadre de nos projets actuels et à venir. Le portage de cette extension eZ vers Magento est déjà à l’étude chez nous. Nous serions donc ravis de pouvoir contribuer de manière active à un groupe de travail sur la question et de confronter un peu nos visions de la chose!

    A ta disposition pour avancer sur le sujet!

  4. 4. Philippe Humeau Dit :

    Je serai ravis de participer à cela également. Le thread reste ouvert afin de voir si on peut récupérer d’autres motivés. (Les intéressés, on peut discuter par mail directement : [email protected])

  5. 5. Gabriel - Fragento Dit :

    C’est vrai que si en plus des optimisations dont tu parles dans le reste des articles et dont tu as parlé au Barcamp, il y a la possibilité de gagner encore plus… Avec un facteur 10…

    Tu avais parlé d’un rapport de 1 à 50, dans cet article tu évoques plutot un rapport de 1 à 10, qu’est-ce qui désormais amène à une réduction de l’amélioration attendue ? ;)

  6. 6. Philippe Humeau Dit :

    Ce sont des ordres d’idées, je pense au moins 10, mais nos amis de smile notamment pourront nous donner une idée plus précise des gains :)

  7. 7. Patrice Bertrand - Smile Dit :

    Déjà, le minimum, c’est de gérer en cache ordinaire, genre Squid, toutes les pages qui peuvent l’être. On peut distinguer déjà toutes les pages de catalogue pour un user non identifié et sans panier. Celles-ci sont cachables, et représentent facilement 50% des pages servies. Avec des petites questions malgré tout, telles que stocks et commentaires. Mais sur un site à forte charge, même un cache de 5 minutes a des effets importants. Pour les commentaires, la réactivité n’est pas déterminante, mais pour le stock, ça peut être critique. On a deux voies possibles ici: soit considérer le stock comme un fragment ESI agrégé à la page cachée (mais c’est pas simple), soit gérer une invalidation de cache sur certains changements de stock, en particulier lorsqu’il passe à zéro.

    Reste ensuite les cas de (1) utilisateur non identifié mais avec panier initialisé, et (2) utilisateur identifié.

    Pour le (1) on aimerait bien pouvoir continuer d’utiliser les pages catalogue et produit cachées, mais on a quelque part un bloc « mon panier » qui est dynamique. Une solution est de gérer ce bloc de manière indépendante, et de l’intégrer à la page soit côté client avec un peu d’Ajax, soit côté serveur avec un dispositif genre ESI, SSI, ou encore l’outil de cache-agrégateur « WAT », de Smile (open source). Si on arrive à couvrir le cas (0) de l’anonyme sans panier et le cas (1) de l’anonyme avec panier, alors on doit avoir jusqu’à 80 % des pages.

    Reste le cas (2) de l’utilisateur identifié, et se pose la question du degré de personnalisation des pages selon le profil, typiquement les suggestions de produits. Si on parvient à isoler les blocs personnalisés, on peut essayer de recourir aux mêmes solutions, mais ce sera un peu plus complexe.

    Ca c’est du côté cache par bloc (ou par fragments) et intégration. Après, il y a tout un autre volet de recherche du côté gestion des données. Typiquement, pour tout ce qui est en lecture seule ou presque (le cas de l’utilisateur non identifié et sans panier), on peut facilement distribuer le trafic sur N serveurs esclaves de réplication d’un maître. Ici, on ne gagne pas en performances, mais du moins en extensibilité. L’idée de distinguer les requêtes en lecture de celles en écriture est une piste, mais pas si simple, car la réplication implique des incohérences transitoires, de sorte qu’on ne peut pas accepter qu’une même session fasse une écriture à gauche, suivie d’une lecture à droite. Il faudrait dire alors que une fois la première écriture réalisée, la session reste affectée au cluster maître.

    Bon, à suivre…

Poster une réponse