spip . blog

La Vérité sur le 3 Septembre

(le concombre masqué) — 2010-09-03T13:48:33Z

Non, SPIP n'est pour rien dans la grande panne de l'Internet du 3 septembre 2010. SPIP-Blog a mené l'enquête. Et révèle, en exclusivité, ce qui s'est réellement passé et le nom du vrai coupable.

Ce matin à 05h20, tous les sites SPIP se sont tus. Simultanément. De ce grand silence, on entendit progressivment monter les lamentations d'un, puis de deux webmestres, rapidement rejoints par une foule de spipeurs au bord de la crise de nerfs : « Mon site SPIP ! Mon site SPIP ! » Misère, misère...


Un précédent, sur l'atoll de Bikini (1946)

Toute cette douleur était provoquée par la disparition collective et soudaine des articles, de tous les articles, qui s'étaient fait la malle pour rejoindre les limbes de l'espace privé. Qui est le coupable !?!

À rebours de tout semblant de vérité, la documentation officielle prétend qu'il s'agissait d'un BUG. Non ! Notre enquête nous permet de démontrer que la terrible justification de ce déchaînements des forces obscures ne réside pas dans SPIP, non ! Mais, dans l'arithmétique !

Oui, nous osons le dire ici, avec l'aide des meilleurs experts en architecture informatique, la source du mal se trouve dans un chiffre : 32. Trente-deux — j'épelle ton nom — bits. 32 malheureux bits, pas assez nombreux sans doute pour supporter la fougue visionnaire de SPIP — lequel rêve d'un temps débarrassé de toute contingence binaire, s'étalant à l'infini sans jamais percuter le mur, le grand mur, le formidable mur du 19 janvier 2038.

Eussent-ils été 33, ces bits, SPIP aurait passé sans anicroche le cap du désormais tristement célèbre 3 septembre 2010.

Qu'on se rassure ; SPIP a montré ses capacités d'anticipation en pointant du doigt, 27 ans à l'avance, le terrible bug de l'an 2038. Et, s'il avait été en ligne en 1990, nul ne peut douter désormais qu'il aurait permis de démystifier avec dix ans d'avance le soi-disant « bug de l'an 2000 », épargnant ainsi des milliards d'euros à l'industrie mondiale.

Ça s'appelle avoir un coup d'avance. Eh ouais, mon pote !

C'est l'été : SPIP 2.1.1 est dans les bacs

(le concombre masqué) — 2010-07-30T12:08:58Z

Bonjour, une nouvelle version de SPIP arrive pendant cette periode estivale. Pas loin de 3 mois après la sortie de la version 2.1, la version 2.1.1 pointe le bout de son nez. Comme d'habitude vous pouvez la télécharger ici : http://www.spip.net/fr_download

La raison principale de la sortie de cette version est la découverte d'une injection potentielle de code JavaScript, qui est à présent corrigée. Des erreurs moins graves ont aussi été éliminées et quelques fonctionnalitées ajoutées.

Vous trouverez la liste exhaustive des changements dans le fichier CHANGELOG à la racine de votre SPIP. http://trac.rezo.net/trac/spip/brow...

Et en essayant de formuler plus simplement voici cette liste :

sur le serveur virtuel SQL suite à l'unification de son traitement d'erreurs pour tous les portages (le portage PostGres en particulier avait subi plusieurs régressions) ;

sur la gestion des bases SQL multiples ou en multi-serveur, à présent plus cohérente et intuitive.

certaines balises et fonctions avaient des lacunes qui ont été corrigés notamment pour permettre à terme de configurer les plugins avec un autre outil que le plugin CFG. Il s'agit de :
- la balise #PLUGIN, qui fournit à présent toutes les informations figurant dans plugin.xml
- la balise #URL_ECRIRE, qui renvoie la chaîne vide si son argument est un script indisponible
- la balise #ACTION_FORMULAIRE dont le premier argument vaut #ENVaction par défaut
- la fonction plugins_afficher_plugin_dist, qui fournit automatiquement un lien vers le script ou squelette configurer_NOM_DU_PLUGIN s'il existe
- la fonction maj_while, qui sait maintenant effectuer les mises à jour des tables d'un plugin
- les fonction lire_meta, ecrire_meta, effacer_meta, qui peuvent s'appliquer à d'autres tables des metas que la table standard.

la balise #INTRODUCTION fonctionne désormais pour les rubriques comme elle fonctionnait déjà pour les articles (intégration du champ #DESCRIPTIF)

toutes les balises LOGO_xxx fonctionnent désormais selon les mêmes normes :
- #LOGO_xxx200, 0 produisant l'équivalent du code [(#LOGO_xxx|image_reduire200, 0)] ;
- LOGO_DOCUMENT** retournant le bon chemin vers le fichier de vignette

un document peut désormais être marqué comme lié à plusieurs objets (articles,...)

Correction d'un bug sur des CVT complexes

réparation des statistiques en CSV

ajout du type='mime/type' sur le raccourci [->doc1]

contrôler le statut d'un article lors de la demande de changement de statut, afin d'éviter de reproposer un article déjà publié (#1932)

en cas de connexion sql morte, un vieux cache exploitable doit passer par gunzip

utiliser la fonction json_encode() native quand elle existe

gérer les caches sessionnés à plat et non plus dans un sous-répertoire ; utiliser les données du cache plutôt que filemtime.

correction d'un gros bug sur la gestion de
header('HTTP/1.1 404 Not Found');

amélioration de lignes_longues qui introduisait des espaces en pagaille

permettre la recherche de forum par IP, et afficher tous les liens même s'ils sont hackés par des
[style=position:relative left:-999px]

un mode TEST : des define() judicieux permettent d'invalider microblog et envois d'email

sécurite du javascript sur la fonction informer_auteur (crédit : Dotsafe)

supprimer le contrôle de date sur les articles très vieux (Mathieu Lopes)

compatibilité IPv6, champ ip de la table spip_forum ( Senjamin Sonntag)

correction d'un bug de lignes_longues utilisé sur les forums (espaces surnuméraires introduits par erreur dans la 2.1)

pipeline post_insertion, permet aux plugins de rattacher des objets aux en attente au moment de la creation en base de l'objet principal+ correction sur le pipeline pre_insertion pour spip_auteurs

securité sur la declaration des bases externes (Thomas Sutton)

prise en compte des progid:DXImageTransform.Microsoft.AlphaImageLoader(src=...) dans le compacteur de CSS

inclusion des fichiers fonctions quand on utilise la matrice

correction du bug du W dans certaines versions d'Opera et de IE qui déclenchaient la sauvegarde de l'article en cours d'edition (#1940)

rétablir l'utilisation des accents dans les mots de passe (avait été cassé par le passage à sha256) (#1945)

correction du bug de lenteur lors de l'enregistrement de révisions (patch par equipement)

correction de la fonction form_hidden avec les urls html

les admins peuvent à nouveau changer leur adresse mail sans passer par une confirmation mail (bug introduit en 2.1)

vidage du cache chemin sur var_mode=recalcul même si on a perdu son cookie d'admin

var2js est conforme a json_encode

correction de la perte de contexte sur les urls propre ou arbo de la forme article32.html

direction_css peut etre utilisé sur des css en squelettes (si le squelette a l'extension .css.html)

fonction charger_filtre() pour charger et chercher un filtre depuis le php

#PLUGINxxx,tout permet de recuperer toutes les infos du plugin (eric)

correction d'un bug sur la pagination indirecte lorsque le pas de pagination est dynamique

appels a notification sur instituerbreve et instituersite

A noter aussi que si vous êtes restes en 2.0 une nouvelle version a ete generee pour corriger le trou de securité, vous pouvez la telecharger ici : http://files.spip.org/spip/archives...

Pour information, vous recevez ce mail car vous êtes abonné(e)s a l'une de ces listes :

spip-dev : la liste des developpeurs - http://listes.rezo.net/mailman/list...
spip-user : la liste d'entraides des utilisateurs - http://listes.rezo.net/mailman/list...
spip-zone : la liste de developpements collaboratifs - http://listes.rezo.net/mailman/list...
spip-trad : la liste de discussion des traducteurs - http://listes.rezo.net/mailman/list...
spip-ann : la liste des annonces importantes de SPIP ( 2 a 3 mails par an) - http://listes.rezo.net/mailman/list...

Mais comme nous sommes aussi "hype/modernes/marketeux", nous utilisons aussi les outils de masses à la mode :

twiiiiiter : http://twitter.com/spipeau
Fessebook : http://www.facebook.com/pages/SPIP/...
identica : http://spip.org

CMS et sites à fort trafic : parlons chiffres !

(cedric) — 2010-07-19T08:34:01Z

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 ».

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

[2] Je 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.

[3] Le 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.

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

Poésie

(le concombre masqué) — 2010-06-16T21:06:26Z

« Si belle soit-elle, une construction inutilisée n'est qu'entropie et obésité dans un core. »

Cerdic

Ajax Parallel Loading : accélérer un site SPIP

(cedric) — 2010-06-06T18:13:54Z

Où l'on découvre une proposition innovante de Facebook pour accélérer les sites Web, qui fait rêver Drupal, et déjà prête à l'emploi dans SPIP. Quand on vous dit de ne pas s'arrêter aux préjugés...

Tout commence par un RT

Cette histoire croustillante commence par un ReTwitt d'un post de Dries Buytaert (pour ceux qui ne suivent pas, le créateur de Drupal) qui apparait dans ma timeline (http://twitter.com/Dries/status/154...) :

We should look into a "Facebook BigPipe"-like solution for Drupal 8 : http://bit.ly/9oFLaS #drupal #performance #todolist

Tiens qu'est-ce donc que cette solution magique de Facebook pour améliorer les performances d'un site, et qui intéresse Dries ?

La proposition de Facebook

Ni une, ni deux, je file sur l'article technique (attention, c'est du Facebook dedans, ne cliquez pas si vous tenez à votre vie privée).

En résumé, pour ceux qui n'ont pas activé leur TOR ou ne comprennent pas l'anglais, l'auteur propose de rendre disponible les pages web dans le navigateur plus rapidement en les découpant en morceaux :

un morceau ossature principal envoyé au plus vite au visiteur ;
plusieurs morceaux de contenu (appelés pagelet), calculés et envoyés séparément.

La page complète est reconstituée dans le navigateur par une fonction javascript.

Ainsi, le rendu et l'interprétation des CSS et JS peuvent démarrer plus tôt dans le navigateur, et la page complète peut être construite par plusieurs processus séparés, en parallèle, sur le serveur.

Mais ça me rappelle quelque chose ...

Intéressant, mais n'ai-je pas l'impression d'avoir déjà vu ça quelque part ? Ah oui ! A tout seigneur, tout honneur, c'est à Fil que l'on doit la première initiative dans ce sens dans SPIP : http://zone.spip.org/trac/spip-zone...

Son plugin inclure-ajaxload permet d'ajouter une condition {ajaxload} sur la balise INCLURE de SPIP.

Le principe ressemble à ce que facebook propose : au lieu d'assembler la page au moment de son calcul, l'inclusion est remplacée par un morceau de javascript envoyé au navigateur, qui va provoquer le chargement du morceau de page séparément de la partie principale de la page.

L'assemblage de la page n'est donc pas réalisée au moment du calcul, côté serveur, mais dans le navigateur, côté client.

Cette première expérimentation était intéressante, mais nécessitait de modifier le squelette pour en bénéficier.

Industrialisons avec Zpip

Le concept de Facebook "une ossature principale qui charge des morceaux de page", cela évoque, pour ceux qui ont commencé à le pratiquer, le concept de Zpip.

On retrouve dans Zpip cette idée d'ossature principale de page, organisée ensuite en blocs de contenus. Sauf que tout est assemblé côté serveur.

Alors justement, je me suis dit qu'il devrait être facile d'automatiser un fonctionnement proche de ce que propose Facebook.

De fait, quelque commit plus tard, Zpip contient une fonctionnalité appelée "Ajax Parallel Loading".

Le plus intéressant est que cette fonctionnalité ne nécessite aucune modification de squelettes. Il suffit de l'activer par un define pour préciser quels blocs doivent être chargés en parallèle.

Voyons cela en exemple sur SPIP-Contrib. Le site est construit sur la base de Zpip, avec un bloc supplémentaire, nommé "more", qui contient en fait les commentaires en pleine largeur sur les pages d'article.

Ce bloc est ajouté en listant les blocs de Zpip dans une globale :

Ensuite, pour fluidifier le chargement des pages, on indique à Zpip que l'on veut charger les deux blocs 'contenu' et 'more' en parallèle du reste de la page :

Tout cela se retrouve dans http://zone.spip.org/trac/spip-zone...

Le résultat est visible directement sur http://www.spip-contrib.net. La page est d'abord chargé avec son ossature, puis le contenu principal, et enfin les forums.

Au final, le temps total de chargement de la page n'est pas plus rapide pour le visiteur, mais il se dégage une impression de fluidité. Au lieu d'attendre devant une roue qui tourne dans son navigateur, il voit tout de suite la page se charger, puis le contenu principal. De plus, ce contenu est disponible plus rapidement car il n'est pas nécessaire d'attendre les forums qui arrivent après, et sont traditionnellement plus lourds et longs à calculer.

Plus intéressant encore, et non évoqué par Facebook, le référencement du site n'est pas dégradé par cette méthode. En effet, les robots indexeur des moteurs de recherche sont connus. Et comme la méthode implémentée par Zpip est automatique, il est facile de leur servir la page complète, avec tout son contenu, au lieu d'une page coquille vide.

On peut donc sans hésiter affirmer que la solution implémentée est sur ce point meilleure que celle évoquée par FaceBook !

SPIP toujours en pointe !

Encore une occasion de démontrer que SPIP reste à la pointe. N'en déplaise aux mauvaises langues qui s'acharnent à le traiter de vieillot, confondant certainement maturité et obsolescence.

Mieux encore, ainsi qu'on avait déjà pu l'aborder à propos des requêtes SQL et de la charge serveur, son architecture interne, basée sur un langage de templating compilé et caché lui procure de nombreux avantages.

Exploitée au mieux par le modèle de squelettes Zpip, cette architecture permet au final des prouesses techniques dans un temps qui doit laisser Dries songeur ...

Esprit Core

(James) — 2010-05-19T05:49:52Z

Au cours du dernier week-end Troglo, les yeux de certains ont pu se poser, par hasard, sur la manche du manteau de Rastapopoulos :


Esprit Core: Tatoué sur le bras gauche de toute la team ?

« Esprit Core », tout un symbole ! :-)

Programmer avec SPIP le livre papier

(Ben.) — 2010-05-17T21:28:27Z

Si vous avez raté l'un des 40 exemplaires de la troglo, tout n'est pas perdu , il est maintenant en vente sur lulu à l'adresse suivante : Programmer avec SPIP


Programmer avec SPIP: Photo de tetue

P.S peut-être, dans quelques années, trouverez-vous sur Ebay, l'un des 41 exemplaires uniques dédicacés par son auteur, Matthieu Marcillaud.

Gai du loir :)

(davux) — 2010-05-17T06:59:26Z

Quelques jours qui s'achèvent dans ces gr0ttes blanches, en compagnie de tous ces nicks et adresses mail devenus des visages, des voix, des discussions, des rythmes, des rires, des ~~jennifer29~~exposés passionnés, des histoires... Comme on a tort (moi le premier) de croire que tout ça est secondaire dans le monde du cyber-travail collaboratif distant...

Je flotte encore un peu (et c'est pas la Westmalle). C'était incroyable, merci.

Et maintenant, c'est parti pour 1200 bornes en stop, ouéééé !

La petite bête qui monte, qui monte ....

(erational) — 2010-05-11T16:24:14Z

(d'après les dates de http://www.spip.net/rubrique155.html)

[1]

[1] réalisé avec le plugin jpgraph avec le code

 |type_graphe=courbe
 |titre=Historique des versions de SPIP 
 |donnee=1.0;1.4;1.6;1.7;1.8;1.9;1.9;1.92;2.0;2.1
 |largeur=460
 |hauteur=300
 |legende=2001;2002;2003;2004;2005;2006;2007;2008;2009;2010
 |couleur=green
 >

Dix ans de retard ...

(cedric) — 2010-05-10T13:48:01Z

twitter c'est sympa, on rigole encore plus que sur IRC des fois ...

Voilà, comme la vie c'est calme, des fois, j'ai ouvert un compte twitter pour mon-lapin-qui-me-parle, et je suis un peu des gens.

Des fois c'est vraiment mort, alors je cherche même ceux qui parlent de SPIP sur twitter. C'est génial, y a des experts avec des avis éclairé, constructifs et tout. Des ingénieurs du Web même.

(C'est un échange twitter, donc il faut le lire de bas en haut, si vous n'avez pas l'habitude)

Tout le sel de l'affaire, c'est d'apprendre que SPIP a dix ans de retard sur des outils qui n'existaient pas il y a encore 6 ans...

Pour être précis, je proposais à mon interlocuteur de comparer l'expérience utilisateur entre (au hasard) ce formulaire de commentaires et celui-là, en cliquant simplement sur le bouton sans rien remplir.

Juste un exemple concret pour avoir une discussion constructive.

Mais visiblement je suis un peu trop pragmatique, et il faut croire que l'expérience utilisateur n'est pas un critère important dans le choix de l'outil de publication.

Aucune chance que SPIP ne rattrape ses dix ans de retards donc...