Augmenter la rapidité de son blog en passant de WordPress à Plone ?

[ 9 ] Commentaires
Share

L’augmentation de la rapidité de mon blog est un sujet que je rumine assez fréquemment, et qui a d’ailleurs tendance à empiéter sur ma vie « professionnelle », où j’ai une certaine tendance à favoriser toute évolution en terme de « temps d’exécution », même si celle-ci n’est pas demandée/payée. Faisant actuellement du développement Python, et ayant un certain attrait pour ça, je me suis donc demandé quel serait le gain en performance pour un blog tel que le mien, en passant du CMS WordPress au CMS Plone, qui me semble être le plus populaire dans la communauté Python.    

D’abord le pourquoi : Pourquoi continuer à s’entêter à vouloir faire davantage de traitements par unité de temps sur des même machines, alors que le coût du matériel baisse sans cesse, et qu’il suffirait d’investir (peu) dans des serveurs plus puissants ?

La réponse est simple : j’ai eu la preuve sous mes yeux que c’était possible, et que, avec un peu de technique/connaissance/travail, on pouvait faire des choses incroyablement rapides, même avec des ordinateurs aujourd’hui considérés comme « vieux ». Rien que parce que les MegaHertz des processeurs constituent des millions de calculs par secondes, et donc que cette fréquence peut suffire, si elle est bien utilisée, à servir un nombre déjà énorme de pages sur un site.

Le problème est donc de coder dans un langage assez rapide (car assez proche du langage machine ou assez compilé) pour rapprocher les traitements à exécuter des fonctions de base du processeur. C’est possible avec des langages tels que le python (quand il est compilé), ou encore plus simplement avec Java, mais évidemment, cela freine toute simplicité de modification du code à la volée (car une compilation est nécessaire), comme le permet le PHP (qui y perd donc sa rapidité, car il est « relu » à chaque fois) (même si lui aussi peut être compilé/mis en cache, par exemple avec PHP Accelerator).

Bref, au final, je me demandais si un CMS « évolué » aurait un temps d’exécution meilleur en étant codé avec un autre langage (en l’occurrence, pour Plone, c’est Python). Dans « évolué », j’entends : « en ayant une perspective de fonctionnalités équivalentes » (c’est à dire avec un système d’extension). Le mieux pour faire un tel comparatif serait de le faire serait de le faire sur un même serveur (disons Apache + mod_python) et avec une même BDD (même serveur pour permettre d’être facilement interchangeable, et de ne comparer les performances propres que d’un seul maillon de la chaine). Allons à l’essentiel : à part le billet suivant « Notes on migrating this blog from WordPress to Plone« , ainsi que le tutoriel sur le site de Plone.org, je n’ai pas trouvé grand chose traitant de Plone et Apache/MySQL, étant donné que celui-ci étant bien plus conseillé d’être mis dans un environnement Zope+Plone+Blob. Le billet le plus intéressant sur les performances de Ploneque j’ai pu trouver  face à WordPress est celui-là : « Plone 4, un CMS plus rapide que WordPress« , qui appelle ce site.

On voit que Plone a des performances approchant le double de celles de WordPress. Sur le site de Plone, le graphique est un peu différent (performances trois fois supérieures à celles de WordPress) :

Ailleurs, sur 01net, un tableau comparatif de plusieurs CMS n’est pas très favorable aux performances de Plone (3/5 en « Robustesse et Performance »), à l’inverse de de eXo Platform, en Java, qui s’en sort beaucoup mieux (4,5/5), et en dessous de Typo3 et Drupal, tous deux (3,5/5) en PHP.

Alors, que faire ? Pour résumer, il ne semble pas que Plone s’en sorte beaucoup mieux que ce que j’aurais espéré par rapport à WordPress. Changer de CMS python alors ? Si je regarde chez DjangoCMS, PyLucid, ou Skeletonz, je ne suis pas sûr de trouver des fonctionnalités équivalentes à ce qu’il y a sur WordPress (grosse communauté, et grosse base de plugins/extensions). La solution pourrait donc venir d’ailleurs : je vois venir l’avènement progressif des CMS Ruby/Rails avec Phusion Passenger/Mod_Rails qui fonctionne avec Nginx, et donc les performances sont tout à fait bluffantes. Reste bien sûr à aligner les fonctionnalités, mais il semble que les projets de CMS en Ruby ne manquent pas, donc il ne me reste plus qu’à aller voir de ce côté là pour trouver mon bonheur 🙂

Vous serez peut-être intéressé :

9 commentaires sur ce billet

  1. epommate dit :

    Heuh… 2,5 requêtes par seconde, c’est pas très impressionnant ! Mais alors 1 requêtes/seconde, alors là, c’est carrément minable, si c’était vraiment le cas, je ne pense pas que beaucoup de gens utilise WP 😉

    > (même si lui aussi peut être compilé/mis en cache, par exemple avec PHP Accelerator). »

    C’est un point extrêmement important, c’est le premier facteur d’accélération du calcul des pages, surtout pour des usines à gaz comme WP !

    RépondreRépondre
  2. Louis dit :

    @epommate: Attention, sur le billet que j’ai linké, ils parlent de l’utilisation de WP/Plone out-of-the-box, sans aucune amélioration, et sans doute sur le même serveur. Je ne sais pas si le 1s est significatif, mais je pense que c’est plutôt le rapport de temps qui est important.

    RépondreRépondre
  3. insy dit :

    Ruby plus performant que Python et PHP ? Tu es bien le premier à dire ça ! Il suffit de voir les fermes de cluster requises pour faire tourner des applications qui n’auraient justifiés que bien moins de serveur en Python et même en PHP. Ce langage a fait de gros progrès dernièrement avec la 1.9 mais il reste encore pas mal de chemin à parcourir pour égaler ses ancêtres.
    De même, quel idée de tester avec Apache pour Python, il vaut mieux utiliser Nginx WSGI ou Tornado Web Server.

    Et de toute façon, les performances de ces usines à gaz seront toujours inférieures à un code fait sur mesure pour ses propres besoins 😉

    RépondreRépondre
  4. Louis dit :

    @insy: Oui, je sais bien que Ruby est à priori plus lent que beaucoup de choses, mais je disais plus exactement que la solution Ruby+Phusion/Nginx serait plus rapide que Python+Apache+mod_python.

    Pour Nginx+WSGI, je pense que c’est effectivement la meilleure solution, même si je ne l’ai pas beaucoup vue pour Plone (et il est possible que la configuration/rewriting d’URL soit de base configuré pour Apache et pas Nginx).

    Et enfin, pour le codage pour ses propres besoins, je pense qu’effectivement, c’est peut-être le plus adapté (par définitions 🙂 ), mais pas forcément le plus rapide/pratique. Je ne pense pas m’y connaitre assez en python pour me développer un CMS comme ça, direct 🙂

    RépondreRépondre
  5. Brian dit :

    J’ai bossé 6 mois avec Plone l’année dernière chez Bull, et franchement performances mises à part, c’est quand même une usine à gaz. Une fois passé le stade de l’apprentissage, on se rend compte de la puissance du truc, mais niveau perfs pour moi c’est pas encore ça.

    Alors faire son blog sous Plone plutôt que WordPress, j’en vois pas l’intérêt, à part pour Python xD

    RépondreRépondre
  6. Louis dit :

    @Brian: Ben l’avantage serait les performances en temps de génération des pages, mais au vu des graphes que j’ai trouvé, c’est pas fantastique, et ça me semble négligeable par rapport au reste des trucs à envoyer (fichiers statiques, et pour ça y’a Nginx).

    RépondreRépondre
  7. Louis dit :

    @lesaintsgeosmois: Sur le billet que tu donnes, les performances de Spip ont l’air très sympa effectivement (rapport de 1 à 10 par rapport à ce que fait WordPress !). Je vais regarder ça.

    RépondreRépondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *