Après le fiasco de lancement de notre site national, que dis-je, notre étendard à l’étranger, france.fr [1] je lis ici et là que, forcément, un site conçu sur un CMS c’est pas bien robuste.
Aussi me parait-il utile d’aborder le sujet sous un angle chiffré, puisque depuis un moment j’essaye de construire une échelle de valeur parmi les outils courants du marché.
Il apparaît ainsi que si les outils à la mode ont en effet des capacités réduites, ce n’est pas une généralité : SPIP s’en tire bien mieux pour servir un site à forte affluence et permet de servir 4 à 10 fois plus de pages que ces outils.
Comparons
Wordpress
Commençons par le moteur de blog le plus répandu. Présent aux RMLL, où se tenait une conférence de présentation de l’outil de traduction de Wordpress, j’ai pu glaner l’information que Wordpress.com était hébergé sur rien moins que 1300 serveurs (environ, ne chipotons pas).
Si je ramène cela au trafic déclaré sur l’ensemble du domaine wordpress.com, de l’ordre de 60 000 000 pages/jour, je peux en déduire un ratio moyen d’environ 46 000 pages/jour/serveur.
Drupal
J’ai déjà eu l’occasion de parler de performance comparée entre Drupal et SPIP sur ce blog, et par ici. J’ai pu aussi trouver des infos intéressantes sur un retour d’expérience d’Edipresse [2].
À travers ces recoupements j’en suis arrivé à un ordre de grandeur de capacité de l’ordre de 125 000 pages/jour/serveur pour les sites construits sur Drupal.
SPIP
SPIP compte quelques gros sites à fort trafic comme agoravox.fr et france-info.com desquels j’ai pu avoir un retour d’expérience direct ou indirect.
La limite de capacité se situe pour SPIP vers 500 000 pages/jour/serveur : c’est ce que je sais faire avec un SPIP, et on peut lire ici que d’autres y arrivent aussi.
TYPO3
Je manque de références pour TYPO3. J’ai pu assister à une conférence aux RMLL sur l’optimisation de sites sous TYPO3.
J’en ai compris que le moteur de TYPO3 était reconnu comme lent (en particulier TypoScript est interprété), et que l’optimisation d’un site sous TYPO3 passait par du cache HTML statique [3] précisément pour éviter de solliciter le moteur de TYPO3.
J’ai essayé d’avoir un ordre de grandeur de capacité, mais l’orateur n’a pas pu répondre à ma question.
Mon outil préféré X
Comparer les outils est une chose bien difficile en l’absence d’étalon.
Aussi je suis preneur de tout retour d’expérience sur l’un des outils ci-dessus ou tout autre outil ou framework. En particulier, je n’ai aucun chiffre en ce qui concerne la capacité de service d’un outil comme Joomla [4].
L’idéal serait de définir un projet standard, un serveur étalon, et que chaque communauté construise le meilleur projet possible sur la base de son outil et le soumette à des tests de charge.
Des coûts de possession bien différents selon les outils
Ces chiffres, même si ils ne sont certainement pas précis à la virgule près, permettent de fixer les ordres de grandeur. Ainsi là ou un site SPIP pourra tenir sur un serveur, il faudra en compter 4 pour absorber le même trafic en Drupal et 10 sous Wordpress.
Le coût d’hébergement et de maintenance grimpe lui plus vite, car le besoin de maintenance et d’intervention d’admin sys augmente généralement plus vite que le nombre de serveurs, du fait de la complexité croissante de l’architecture (filers réseau, SQL maîtres et esclaves, répartition de charge ...).
Il n’est pas surprenant que cet état de fait soit en général passé sous silence par les agences web hype et autres SSII dans le vent. Vendre un projet sur un outil qui va générer de la maintenance est toujours bon pour le commerce.
Mais pour les structures pour qui le coût de possession et/ou l’indépendance sont vitales, un outil comme SPIP est tout indiqué.
Mais pourquoi SPIP serait-il meilleur ?
La raison profonde tient à son histoire : SPIP est développé et maintenu par une communauté qui ne dépend d’aucun acteur économique. Ce n’est donc pas un produit d’appel dont le but serait de vendre du service autour.
Par ailleurs, SPIP est très utilisé dans le monde militant et associatif. Dans ce monde là, les crédits sont toujours comptés et toute dégradation des performance de SPIP ayant un impact sur le coût d’hébergement nous est très vite remonté par des utilisateurs pour qui c’est problématique.
Ce résultat est donc le fruit d’une attention permanente dans le développement. D’un point de vue technique, il repose aussi sur certains fondamentaux liés à l’architecture de SPIP :
- un langage de template compilé
- un système de boucle pour abstraire les requêtes
- une optimisation automatique des dites requêtes générées
- un profileur SQL intégré
- un cache intégré qui fonctionne par blocs et préserve les partie dynamiques de la page
- un compresseur qui minifie et concatène automatiquement js+css
Un résultat important et qui distingue SPIP des autres outils est qu’il est capable nativement de servir les pages en cache sans aucune requête SQL (et j’insiste sur le fait qu’il ne s’agit pas d’un cache html statique).
SPIP permet donc en production une sollicitation réduite du serveur SQL, et une certaine tolérance à la panne vis à vis de celui-ci.
Choisissez un outil écologique !
J’espère que ces chiffres vous permettront de mieux anticiper les problèmes de charge de vos projets, et, pourquoi pas, de choisir l’outil le plus performant en évitant de le confondre avec un outil à la mode !
C’est un message que nous avons porté aux RMLL dans une présentation matinale malheureusement peu suivie : « SPIP, système de publication écologique ».