Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Sport 24 et 01 Informatique

Sport 24 et 01 Informatique

Le problème posé

Nous étudions ici deux sites différents, réalisés par Smile, qui mettent en œuvre des principes d’architecture semblables.

*Le contexte est le suivant:

  • Ces sites ont une large part de gestion de contenus : des journalistes écrivent des articles, qui sont mis en forme au moyen de templates, puis mis en ligne. Il existe d’excellents outils open source prêts à l’emploi qui couvrent toutes les fonctionnalités requises à cet égard.
  • Ces sites ont une forte audience. Dans le cas du site Sport24, on est à 5 millions de visites sur le mois de septembre 2008. Mais plus important encore : le site observe de très forts pics de trafic à l’occasion des événements sportifs.
  • Ces sites ont une part de contenus personnalisés, c'est-à-dire qui changent selon les préférences de l’internaute.
  • Ces sites n’intègrent pas que de la gestion de contenu, mais de nombreuses fonctionnalités périphériques relevant d’une dimension communautaire : blogs, forums, chat, etc., ainsi que des commentaires utilisateurs, qui plus largement sont dans la catégorie des « UGC », « User Generated Content », contenus produits par les utilisateurs.
  • Enfin, dans le cas de Sport24, on a également une fonctionnalité de match en temps réel, où l’historique du match est rafraîchi de manière très rapide.
image176

Axes de solution

Pour de tels sites, le socle est obligatoirement un outil de gestion de contenus, couvrant pour au moins les 2/3 les fonctionnalités attendues.

Il existe une offre très diversifiée de bons outils CMS, « Content Management System », et l’open source domine clairement ce marché. On ne va pas détailler ici l’analyse du choix de solution, sur la base des qualités ou contraintes propres de chaque produit. Pour ces deux sites, le choix s’est porté sur le produit eZ Publish, un excellent CMS en environnement PHP.

eZ Publish offre une configuration dite « en cluster », qui a les caractéristiques suivantes :

  • Les contextes de session sont partagés en base de données, ce qui permet une répartition de charge sans affinité de serveur.
  • Les fichiers média sont également conservés en base de données, donc peuvent être partagés par N frontaux.

eZ Publish présente des performances assez bonnes, mais en présence de pages personnalisées, le cache ne peut pas être très efficace, et l’on peut descendre jusqu’à une dizaine de pages par processeur seulement.

Dans le cas de Sport24, on veut tenir des charges en crête de quelques milliers de pages servies par seconde. On voit qu’en configuration

ordinaire, il faudrait plusieurs centaines de serveurs pour y parvenir ! Il va donc falloir travailler un peu l’architecture.

Agrégation côté client

Pour gérer la personnalisation, ces sites utilisent le mécanisme d’agrégation côté client, c'est-à-dire que certains morceaux de la page sont inséré dans la page coté navigateur par un peu de javascript.

Il s’agit des blocs personnalisés, qui ne peuvent être gérés en cache. Ainsi la plus grande partie de la page bénéficie du cache – comme on le verra plus loin – et seuls les blocs personnalisés sont constitués dynamiquement.

De même, les matchs en temps réel sont rafraîchis à une fréquence élevée en javascript, sans recharger la page.

Agrégation côté serveur

Pour l’agrégation côté serveur, nous avons utilisé le module Server-Side Include (SSI), de Apache, qui précisément permet de constituer des pages en insérant différents fragments aux positions indiquées. C’est finalement une sorte de dispositif de templating, rudimentaire.

Cache Squid en frontal

Bien entendu, nous avons positionné un serveur de cache, ici Squid, en frontal du serveur Apache. Pratiquement toute plateforme web doit avoir un serveur de cache en frontal.

Un unique Squid permet de servir plus de 2000 pages par seconde.

Comme on l’a vu plus haut, la gestion des durées de vie en cache (TTL) peut soit être configurée globalement, soit plutôt spécifiée par le serveur lui-même.

On compte en particulier sur le Squid pour servir tous les fichiers de ressources autres que Html, qui varient peu.

Génération de pages statiques

C’est l’originalité de ces deux plateformes : le CMS ne sert pas directement les pages aux visiteurs, on lui fait générer des pages Html statiques, des fichiers, qui sont ensuite servis par Apache.

C’est un moyen de bénéficier à la fois de toutes les fonctionnalités d’un CMS – et elles sont très nombreuses – et de l’extraordinaire robustesse et performance du statique.

Les journalistes contributeurs utilisent le back-office du CMS pour créer et modifier leurs articles, et gérer les médias.

De manière assez fréquente, un petit script provoque la regénération des pages, ou des fragments Html.

Obtenir des pages statiques, des fichiers Html, à partir d’un CMS est assez facile : il suffit de se faire passer pour un navigateur web, et demander la page en http, puis écrire sur disque le fichier ainsi obtenu. Il faut veiller bien sûr à ce que les liens hypertexte restent corrects dans un contexte statique.

La principale difficulté est ailleurs : on ne peut pas regénérer, par une sorte d’aspiration, l’ensemble du site à haute fréquence. Il faut donc déterminer qu’est-ce qui a changé. Ce n’est pas chose facile, car dans un CMS sophistiqué, il n’y a pas correspondance entre un contenu et une page : le journaliste modifie un article, mais cet article peut apparaître dans différentes pages, sous différents formats. On peut même modifier un pied de page par exemple, qui impactera la totalité des pages.

Nous avons donc réalisé un job qui analyse les impacts des derniers changements, afin de ne regénérer que ce qui est requis.

Diffusion des pages vers les frontaux

Une fois générés les fichiers statiques, fragments de pages Html, on peut les mettre à disposition des frontaux soit par un partage NFS, soit par une réplication RSync. Pour Sport24, nous avons utilisé un NFS, pour 01Informatique, nous avons préféré la réplication.

Schéma d’ensemble

image178

Sur le schéma précédent, on distingue :

  • A gauche, la plateforme de contribution destinée aux journalistes
  • Au centre, le serveur de publication, sur lequel un job spécifique vient analyser les changements et aspirer les pages ou fragments Html.
  • A droite, la plateforme de publication, sur laquelle on distingue :

• Le cache Squid en frontal
• Apache bien sûr
• Le module SSI, qui va réaliser l’agrégation des fragments Html obtenus depuis le serveur NFS.

On a fait figurer également un CMS en production, qui est en charge des blocs personnalisés, insérés dans les pages du côté navigateur.

image180

Sur la figure précédente, on distingue :

  • Tout à fait à droite, l’agrégation côté client, insérant un bloc de contenu au sein d’une page, en invoquant le CMS, qui accède à la même base que les serveurs de contribution.
  • Les contenus média servis directement depuis le Squid.

Enfin, la figure suivante représente la variante 01 Informatique

image182

 

Outre la réplication RSync qui remplace le partage NFS pour un résultat équivalent, on a aussi intégré ici la plateforme de Forum PHP-BB, qui elle est en direct.