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 🙂