Accueil > Ailleurs > CMS et sites à fort trafic : parlons chiffres !

CMS et sites à fort trafic : parlons chiffres !

lundi 19 juillet 2010, par cedric

Après le fiasco de lancement de notre site national, que dis-je, notre étendard à l’étranger, france.fr [1] je lis ici et 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 ».


[1Ne mériterait-il pas lui aussi sa chanson ?

[2Je n’évoque pas ici les 12 serveurs gouvernementaux tombant comme un seul homme sous le poids colossal des 50 000 visites du 14 juillet. En son temps notre brillant SIG avait su appliquer le même traitement à SPIP grâce à son fork Agora, terriblement plus lent.

[3Le recours au cache HTML statique n’est pas une spécificité de TYPO3 : tous les outils le permettent d’une façon ou d’une autre. Avec ce type d’optimisation les performances n’ont plus grand chose à voir avec le CMS et ne dépendent plus que d’APACHE ou équivalent. Le cache HTML statique n’est pas non plus utilisable pour les pages contenant de l’interaction avec les utilisateurs.

[4La présentation sur Joomla aux RMLL était peu informative

Messages

  • Lo ...

    Il y a serveur et serveur aussi non ...

    Genre le gros bouzin 8 cores + X Go de ram + patati patata mal optimisé au niveau d’apache et mysql tire t il plus qu’un moins puissant bien configuré ?

    Quels types de serveurs sont employés dans les tests ? des dedibox v1 ?

    Enfin bref ... c’est difficile à quantifier quand même ces choses là....

  • @kent1 : on est bien d’accord, il faudrait un étalon projet, un étalon serveur. Les chiffres que je donne sont des valeurs moyennes. Quand Wordpress.com utilise 1300 serveurs, montés au fil du temps, on peut présumer qu’il ne s’agit pas de 1300 bi-processeurs 8 cores, mais plutôt de serveurs « moyens ».

    Sur un projet multi-serveur Drupal, on ne va pas non plus choisir des très hauts de gamme, car leur coût/page servie est proportionnellement plus important que sur un moyen de gamme. A partir du moment où on a une infrastructure multi-serveur il est plus intéressant financièrement de mettre 2 serveurs moyens de gamme plutôt qu’un très haut de gamme.

    Dans le cas de SPIP, le chiffre que je donne correspond plutôt à un serveur moyen/haut de gamme (mais pas un très haut de gamme).

  • Je lis ici que Rue89 qui repose sur Drupal, requiert 4 serveurs pour servir en moyenne 2 000 000 visites/mois.

    Avec une hypothèse optimiste 3 pages/visite et un coeff de x1.2 pour les jours de semaine par rapport à la moyenne (plus de trafic en semaine que le week-end), cela donne environ 240 000 pages/jour, soit 60 000 pages/jour/serveur pour Rue89. C’est 2 fois moins que le chiffre que je donne pour Drupal, mais cela correspond à un trafic moyen.

  • Article intéressant ;-)

    Faudra quand même que je réintéresse à Spip :p

    Et le choix Apache / Cherokee / Lighttpd / Nginx ?
    ça influence beaucoup ?

    Bonne soirée,

  • L’article est intéressant et je ne veux en aucun cas lancer une polémique, sincèrement. D’ailleurs je ne connais juste pas SPIP qui semble mériter que j’y passe quelques devoirs de vacances.

    Mais juste pour améliorer vos metrics, sur une des infrastructure Drupal pour laquelle j’officie, on tourne en gros à 108 pages/minutes/machines, ce qui donne les 150k pages/jours dont vous parlez à un détail prés, les charges de toutes les machines sont en ces moment là à 25%. La semaine dernière avec un très très forte affluence on a commencé à avoir des sérieux problèmes de temps de réponse avec un traffic 5x plus important (et là on était logiquement en limite de charge sur les bécanes). Ceci me fait dire que l’on peut à l’aise maintenir un trafic 3 fois supérieure à 159kpps. Maintenant, une fois de plus, je ne doute pas que SPIP soit plus « aux petits oignons » que Drupal, et je suis assez d’accord sur votre remarque concernant « le produit d’appel ». Sans compter que je suis le premier à hurler sur la lourdeur de drupal, même s’il s’agit honnêtement plus d’une question d’usage anarchique de l"outil, que de l’outil lui-même.

    Encore un détail, SPIP n’est pas le seul à servir directement du cache en ne passant pas par la base de données. Drupal+APC en mono-serveur ou Drupal+memcache en multi-serveurs font cela très bien. De même pour l’optimisateur CSS/JS. Pour le reste je vais aller voir ce qu’est ce fameux profiler de requête, cela m’intéresse au plus haut point :)

  • Merci de ton retour. Je nuance ton calcul par le fait que la répartition de charge sur la journée n’est jamais constante : il y a en général très peu de visites la nuit, et le maximum a lieu à en mi-journée.

    Les capabilités dont je parle correspondent bien à un trafic réel, avec cette distorsion de répartition, pas à un trafic théorique basé sur la capacité/minute et multiplié par 24heures*60minutes.

    Ainsi, ton 108 pages/minute/machine doit correspondre en fait à un trafic journalier bien inférieur à 150kpages/jour (plutôt de l’ordre de 60k-70k ?). Si je prend en considération ta charge serveur et que j’applique le coef 3 de trafic que tes machines semblent pouvoir supporter, on serait, sur cette hypothèse, vers 200kpages/jour/machine. C’est un peu mieux que mon estimation, en effet.

    C’est noté pour la capacité de Drupal à cacher via file/APC ou SQL. Mais dans le cas où le cache est stocké par APC ou file, Drupal est-il capable de servir cette page sans *aucun* accès à SQL ?

  • Je ne connais pas SPIP mais je connais pas mal Drupal et surtout TYPO3.
    Pour moi, Drupal est notablement lent, bien plus que TYPO3, et il existe peu de moyens à ma connaissance de le rendre performant.

    TYPO3 par contre à l’inverse des préjugés qu’il se trimballe peut être très rapide, le problème est de trouver les bonnes personnes pour le développement.
    Contrairement à d’autres systèmes TYPO3 est très riche et cette richesse implique donc une certaine complexité. Si elle n’est pas maitrisée, cette complexité peut aboutir à des frustrations et comme nous le savons tous, ce sont en général les gens frustrés qui s’expriment et font la réputation d’un CMS.
    Il est faux de dire que la lenteur de TYPO3 est dûe au langage Typoscript qu’il utilise car celui-ci n’est interprété qu’au premier affichage de la page et une fois que la page est en cache son affichage est quasi instantané.
    Les supposées lenteurs de TYPO3 viennent en général de 2 facteurs principaux : une extension mal développée (comme tout projet open-source, il faut trier le bon grain de l’ivraie) ou une mauvaise utilisation du système de cache. Le système de cache est extrêmement puissant, mais comme tout outil puissant mal maitrisé, il peut produire l’inverse de ce à quoi il est destiné si on s’en sert mal.
    J’ai fait la démonstration à la dernière université d’été TYPO3 qu’on pouvait accélérer un site d’un facteur 10 rien qu’en corrigeant les erreurs de débutant dans l’utilisation du système de cache (donc sans utiliser de cache statique) et vous seriez étonnés de voir combien de personnes font ce genre d’erreur. À vrai dire je suis intervenu sur pas mal de sites réalisés par des agences sur lesquels ces erreurs étaient présentes. Bref, pour moi la réputation de lenteur de TYPO3 vient du fait que ce n’est pas un outil pour bidouilleur, par défaut et si on fait n’importe quoi, oui il peut être très lent mais en se donnant un peu de mal (sans doute un peu plus qu’avec d’autres CMS), il peut rivaliser voire surpasser n’importe quel autre système.

    Je n’ai pas de données en terme de pages vues, uniquement en terme de visiteurs uniques, mais j’ai déjà fait du 50 000 visiteurs uniques/par jour/par serveur.

  • @duch : en reprenant la même hypothèse que plus haut (en général optimiste) de 3 pages/visites en moyenne, cela placerait TYPO3 à 150 000 pages/jour/serveur soit du même ordre que Drupal.

  • le chiffres annonces correspondent a peu pres a mon experience personnelle d hebergement de CMS sur mes serveurs , la ou je me permet de mettre 100 petits sites sous spip, je ne mettrai pas plus de 10 ou 15 drupal.

    a part ca signalons :

    http://planete.drupalfr.org/node/944

    qui pourrai donner d autres arguments interessants sur le sujet

  • @cedric : J’ai validé un peu vite mon commentaire, j’ai oublié de préciser qu’à 50000 visiteurs uniques/jour le serveur en avait encore sous le coude et qu’il s’agissait d’un simple XEON.

    Bref, en extrapolant un peu on devrait pouvoir encore gagner un bon 50k mais bon sur ce site je n’avais pas non plus tuné comme un malade, ce n’était pas la peine.

    C’est certes moins bien que SPIP mais je trouve ça pas mal pour un outil qui est il me semble plus riche fonctionnellement.

    Dans tous les cas, le problème du site france.fr n’a à mon avis pas grand chose à voir avec le nombre ou la configuration des serveurs comme c’était annoncé mais plutôt à une mauvaise utilisation du CMS (comme c’est souvent le cas).

    sinon, je suis partant pour ton projet de site étalon ;-)

    au passage, j’ai écris quelques ressources sur l’optimisation Typo3 dont l’intervenant du RMLL semble s’être inspiré (mais ça n’est peut-être qu’un hasard après tout) :
     http://uni.typo3.ma/uploads/media/optimiser_Typo3_2010.pdf
     http://forum.typo3.fr/index.php?showtopic=14581

    duch

  • Mouais...
    Désolé, mais ces chiffres, c’est vraiment que du vent.... On ne connait ni les serveurs, ni les sites hébergés (optimisés ou grosses daubasses ?), ça ne vaut absolument rien !

    Et puis désolé, mais l’argument du « les CMS sont lourds pour pouvoir faire payer des prestations de maintenance », vous y croyez VRAIMENT ?
    Ils se battent pour optimiser ces solutions opensource, balancez pas des âneries non plus...

    En tout cas, très intéressé par le concept du « projet étalon ». Là, ça parlerait déjà plus !
    Parce que pour l’instant, je suis désolé, mais c’est que du vent...

    Et c’est un gars qui adore Spip qui dit ça !
    Je ne dis pas non plus que telle ou telle solution est plus ou moins rapide... juste que l’article est vide de sens par ces chiffres et son raisonnement !

  • Merci Cédric pour cet article.

  • A mes yeux Spip est quand même vieillissant, difficile de comparer en perf sur une machine Windows 3.1 et Windows 7. Ensuite vous ne parlez pas d’EzPublish qui est une machine de guerre pour la gestion de contenu et qui représente à mon avis la meilleure solution open-source PHP à l’heure actuelle.
    Il faudrait aussi en savoir un peu plus sur les autres plateforme Plone/Zope, Tomcat/Jahia et autres.
    Quoi qu’il en soit, le meilleur moteur de rendu pour du contenu restera la page html statique et les fonctionnalités en plus ralentiront toujours un site. Je n’aurai pas choisi Drupal pour France.fr mais je n’aurai pas non plus opté pour Spip.

  • Bon c’est cool les messages autour de la question de savoir qui à la plus grosse machine de guerre pour publier sur le web.

    Moi perso d’une manière générale les machines de guerre bof bof.

    Ca fait un moment que j’entend que l’on compare les sites les cms les uns avec les autres. Davduf avait au moins monté un projet inteligent sur la question.

    Ce que je propose c’est que l’on organise un gros apero cross communites.

    S’il faut un endroit neutre pour sortir nos machine de guerre par exemple « la cantine ».

    On parlerai des differents aspects des cms, ce qu’il manque en matière de code, les différentes philosophie et ce que cela implique en matière de gestion des publications.

    Par exemple travailler sur des projets commun, là je pense à un systeme de plugin crossplateforme, mais les personnes habituée à coder spip pourait donner de vrais projet.

    Comparer les différents aspects des acces aux base de données, le cache, etc.

    Essayer d’en ressortir du coté de Spip avec un plus grand nombre de base de données supportées, la progression du travail ammorcé par emmanuel sur le moteur de spip afin de faire « progresser » le langage de squelettes, travailler avec d’autres dev php afin de pousser à une integration « complette » avec spip par exemple des logiciels de gestion de bibliotheque, de vente en ligne, gestion d’audit de trafic des sites, de publicités en ligne, de cartographie en ligne (exemple openstreetmap), de bibliotheque ajax, etc.

    wait and see

  • Voir aussi cet article qui réagit à la débâcle du site France.fr qui a été réalisé avec drupal : http://planete.drupalfr.org/node/944.

    A noter cet article de Zdnet où un interviewé se demande si spip n’était pas un choix plus judicieux pour france.fr http://www.zdnet.fr/actualites/francefr-on-est-dans-le-domaine-du-jamais-vu-selon-les-experts-de-l-hebergement-39753424.htm

  • Un article comparant divers CMS (mais pas SPIP) par analyse (brute) du code.

  • La maison blanche utilise drupal non ?

  • ceci dit en passant, loin des polémiques sur « mon cms est meilleur »,
    il est complètement à noter que c’est l’hébergeur qui a changé,
    absolument pas le cms ou l’agence qui a réalisé le site...

    et comme par magie depuis ça marche...

    enfin, je dis ça, je dis rien :)

  • Eh bien moi je peux vous donner nos stats aussi :)

    C’est un site de contenue gratuit, une trentaine de squelettes pour les diverses pages : text, image, mot cle, rubriques, ect...

    1 SPIP version 1.9 derniere mouture avec tous les patchs a ce jour.

    Le site est mutualise et utilise le multilinguisme

    1 server 16mo RAM, dual-processor quad core 5430,

    78,000 articles ;) et poids de la base sql spip 1.7gb

    Traffic mensuel via Google Analytics : 3,000,000 de visiteur uniques, 8,000,000 de pages vues.

    Apres plusieur annee, le secret de la stabilite ca a ete pour nous, le ’cache cool’, aka servir des pages purement static avec un recalcul differe a la demande.

  • Le problème majeur est le manque de docs sur le tuning du CMS. Le forum est peu réactif, donc difficultés à régler les fortes charges.
    Dés qu’un robot passe Spip passe en travaux. Spip est tés fragile avec mySql. Comment régler le cache ? (aucune doc)

  • Difficile de te répondre j, sans aucune information technique. Nativement SPIP supporte très bien les fortes charges, et n’est pas fragile avec mySQL ou tout autre gestionnaire de BDD.

    A chaque fois qu’un site a des problèmes comme le tien, cela résulte, après analyse, de mauvaise manip ou modifications hasardeuses. Quoi qu’il en soit, si tu as besoin d’aide, tu peux t’adresser a l’une des listes utilisateur de SPIP, ou venir poser ton problème sur IRC ( #spip sur freenode.net ou http://www.spip.net/irc )

  • Bonsoir

    Pas mal de grands sites utilisent le CMS ez publish qui est un TANK.

    Et bizarrement ils tiennent la charge sans forcément avoir une grosse archi derrière ...

    Entre autre grâce à Varnish en tant que proxy ...

    Testé et approuvé sur un site à « moyen » trafic.

  • Depuis l’écriture de ce billet le temps a passé : d’un côté les serveurs ont grossis, d’un autre les CMS en général et SPIP en particulier se sont forcément alourdis aussi.

    Un petit retour d’expérience complémentaire tout de même : ces derniers jours, avec un (unique) petit serveur 4 cœur/8 threads, 32Go de Ram, disque SSD, un site en SPIP 3.1 a encaissé 1.3 Millions de visites en 24h (en https).
    Le site a encaissé en continu un rythme soutenu de 35visites/secondes pendant une douzaine d’heures. Le tout sans interruption de trafic ni indisponibilité, même si on a du ajuster quelques réglages serveurs en live (notamment le nombre maxi de process servis par Apache).

    Belle démonstration de performance non ?

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.