Karlesnine

Record de pages vues

Nous avons vue tomber notre record de production le dimanche 27 septembre 5 150 253 pages vue xiti sur Télé-loisirs.fr. La raison de ce record m’échappe mais visiblement les internautes avait une bonne raison de consulter notre site.

L’effet sur la bande passante d’un serveur

Analyse

Quel sont les particularités du site Télé-loisirs.fr ? De son contenue ? De son audience ?

1. 80% de l’audience ce fait entre 18h et 21h. Cela correspond aux personnes qui ce demande quel programme regarder ce soir
2. Chaque fiche programme comporte et dois comporter une images pour illustration et identification du contenu.
3. Très peu de visiteur interagisse avec le contenu, peu de commentaire sur les programmes, peu de notation etc. L’utilisation du site est « informatif ».

En fonction des ces constatations des choix on été fait et des arbitrages rendus :

1. Le moteur de recherche, le forum et autre commentaire sont débrayer durant la pointe d’audience
2. Une séparation en silos du contenu, d’un coter les images, css, javascript purement statique, de l’autre les pages web qui sont plus mouvante et changeante.
3. Un système de cache pour les pages web sur un durée minimum évitant leur recalcule
4. Une mise à jour des donnée variable qui n’est pas immédiate. Cela concerne le nombre de commentaire, la notation (nb étoile).
5. Une mise à jour de la grille des programmes par ordonateur.

En pratique

Ces choix ce traduise dans la pratique par plusieurs solution:

• Les pages web sont généré en php, un fois calculer sont stocké au format html. L’application leur attribue un temps de vie. Elles ne sont régénérés que à l’expiration de leur temps de vie. Ainsi on limite l’utilisation des frontaux web.
• Le serveur web utilisé est lighttpd, plus rapide pour les éléments statique que apache.
• Un sous domaine est dédié aux éléments statiques.
• Un service de cache type CDN est utilisé pour les éléments statique. En conséquence la plate-forme ne crache vraiment que du html.
• Au moment de l’audience maximum le temps de vie des pages mise à cache est « figé ». Aucune pages ne vieilli et donc plus aucun recalcule php est réalisé.
• Un peu avant l’audience maximum la grille de programme est figé et ne fais plus l’objet de mise à jour. Mise à jour qui de toute façon sont extrêmement rare.
• Le serveur de base de donnée Mysql est configurer pour la lecture. Toute écriture en base est donc plus longue. L’utilisation de script de tunnig Mysql est nécessaire à cette étape.
• Utilisation du mod_compress de lighttpd pour « zipper » les fichiers css. Les fichiers css, parfois lourd du fait de refonte de design multiple, sont plus léger et on économise de la bande passante.
• Utilisation du mod_expire de lighttpd pour configurer les mises en cache navigateur des images et css. Les images et css sont donc moins souvent demandées.

Plan de l’architecture

Et pour faire mieux ?

Pour faire mieux et sans réfléchir bien longtemps je pense à différente possibilité, entre autre :

1. Laisser lighttpd et revenir à apache
2. Ne plus faire de cache statique avec l’application
3. Utiliser une couche de reverse proxy en amont des frontaux (squid ou CDN)
4. Utiliser deux serveurs de base de donnée, un pour le contenue statique, l’autre pour le contenu dynamique. Le premier serveur serait configurer pour favoriser la lecture le second pour l’écriture.
5. Peut être un partage de donnée entre frontaux basé sur OCFS2