Jean-Sébastien Mansart .com - Tag - performances

Mon best-of Paris Web 2008 : Performances web

Jean-Sébastien Mansart — Tue, 13 Jan 2009 19:39:00 +0100

On continue la série amorcée hier sur les conférences de Paris Web 2008 avec la présentation d'Eric Daspet et de Nicole Sullivan sur les performances web.

J'ai déjà eu l'occasion de vous parler des performances, j'en reparlerai sûrement lors de la sortie de la v2 de YSlow, mais pour le moment, je vous laisse avec la vidéo.

Cette conférence est une introduction aux performances, elle est très bien faite et montre les points sur lesquels il faut se concentrer.

Eric Daspet et Nicole Sullivan - Performance Web côté client

J'ai pu participer aussi à l'atelier proposé par Eric Daspet et Nicole Sullivan, jai ainsi pu approfondir les concepts et poser des questions en choisissant des exemples concrets.

Vous avez mis en places des préconisations dont je vous parlais ?

Article original écrit par Jean-Sébastien Mansart et publié sur Jean-Sébastien Mansart .com | Lien direct vers l'article | Si vous lisez cet article dans son intégralité sur un autre site que Jean-Sébastien Mansart .com c'est qu'il a été reproduit illégalement et sans autorisation. Merci de le sig naler à son auteur original en cliquant ici | © jsmansart.com.

Performances d'un site web

Jean-Sébastien Mansart — Sun, 23 Nov 2008 11:00:00 +0100

Depuis quelques mois je m'intéresse à deux points particuliers d'un site web : l'accessibilité et les performances.
Les performances web ne sont pas combien de visiteurs un site web a réussi à convertir en acheteur, mais plutôt la rapidité de réponse et d'affichage d'un site dans le navigateur de l'internaute.

Dans le domaine des performances web, en français, il n'existe pas beaucoup de lecture sur internet. Cependant deux blogs traitent du sujet.

Le premier est celui d'Eric Daspet : Performances web, et le second, celui de Nicole Sullivan.

Je lis celui d'Eric Daspet depuis plusieurs mois, et quand j'ai le temps, je me penche d'un peu plus près sur les conseils qu'il donne et regarde ce que je peux mettre en place de mon coté.

Pourquoi se préoccuper des performances des sites web ?

C'est vrai après tout, tout le monde a une connexion de ouf...

Tout le monde ? Pas forcément. Et des fois, tout se joue pour quelques centaines de millisecondes.

Perdre 500ms c’est perdre 20% de traffic pour Google (ou pourquoi il n’y a que dix résultats par page dans les recherches).
Perdre 100ms c’est perdre 1% de ventes pour Amazon.
Réduire de 25% le poids de la page c’est gagner 25% d’utilisateurs à moyen terme pour Google.
Eric Daspet - A quoi ça sert ?

Pour un petit blog comme le mien, ce n'est rien, je n'ai pas un besoin vital de me préoccuper de cet aspect.
Non.

Je m'en sers comme "bac à sable". Je peux tester certaines pratiques, certaines techniques, afin de voir comment les intégrer dans mon travail, les partager avec mes collègues et leur faire comprendre que c'est un point tout aussi important que l'accessibilité ou que la couleur du bouton que veut le client.

Que peut-on faire facilement ?

Dans un premier temps, j'ai donc installé YSlow, un plugin pour firefox qui vient en surcouche de firebug.

YSlow m'a donné un petit D, soit 58 sur 100. Et mon site se chargeait en 3 secondes.

J'ai regardé point par point ce que je pouvais faire, et après avoir lu de la doc un peu partout, j'ai commencé par réduire le poids des images.

Pour ça, il existe un site web fabuleux, créé par Nicole Sullivan et Stoyan Stefanov : smushit. Il suffit de donner l'url de la page, et le service s'occupe de tout. Au final il vous rend un fichier zip avec toutes les images optimisées et, point important, les optimisations ne sont pas destructives. Votre image sera identique pixel par pixel à celle d'origine.

J'ai ensuite tenté de réduire le nombre de requêtes HTTP.

Pour réduire le nombre de requêtes HTTP, on peut :

merger les CSS
merger les JS
privilégier les CSS Sprites

Je n'ai pas été très chanceux sur ce coup, je voulais à tout prix faire un maximum de CSS Sprites, mais dans mon cas, ce n'était pas possible, je n'ai réussi qu'à réduire d'une image le nombre d'images CSS.

J'ai tout de même réussi à merger les trois feuilles de styles pour n'en faire plus qu'une seule, et je l'ai ensuite optimisée avec code beautifier.

Pour les fichiers JavaScript, rien à faire de ce côté là, utilisant dotclear, je préfère laisser les fichiers JS tels quels.

En troisième action, j'ai demandé à mon hébergeur de configurer le mod_expires d'apache.

mod_expires permet de spécifier une date d'expiration du contenu. Tant que la date n'aura pas expirée, votre navigateur ne rechargera pas le contenu en question. Les gains en cache plein sont assez impressionnants.

Vous pouvez régler la date d'expiration par type de contenu, et vous pouvez le faire soit dans la configuration générale d'apache, soit dans votre vhost ou votre .htacess.

Voici par exemple ce que j'utilise :

ExpiresActive on
ExpiresDefault access plus 10 years
ExpiresByType text/html now
ExpiresByType text/xml now

On active le mode expires, par défaut tous les types de contenus expirent dans 10 ans, par contre, le HTML et le XML expirent immédiatement, ce qui évite de vider son cache quand un nouvel article est publié sur le site et sur le flux RSS par exemple.

Au final, avec ces quelques petites choses, avec un cache vide, mon site (d'après mes tests) se charge en 1s, et avec le cache plein en 0,5s. Ce qui me fait maintenant une note C, soit 79 sur 100.
On remarquera aussi qu'avec le cache vide, 26 requêtes sont nécessaires, alors qu'une fois le cache plein, il ne suffit plus que d'une seule requête : la page HTML.

Prochainement, avec mon hébergeur, nous devrions mettre en place le mod_gzip qui permet de compresser à la volée le contenu, et ainsi réduire la consommation en bande passante et, normalement, accélérer l'affichage des pages. Car plus c'est gros, plus c'est lent.

Tout ce travail porte ses fruits, j'ai déjà commencé à modifier la configuration apache de nos serveurs de production, et les graphistes regardent de près smushit et le format PNG-8 qui est beaucoup plus performant que le GIF.

Les performances web, c'est comme l'accessibilité, toujours en mouvement. On n'est jamais fixé, il y a toujours à faire, c'est pour ça que j'aime le web !

A suivre donc...

Optimisation d'un site Plone

Jean-Sébastien Mansart — Tue, 24 Jul 2007 11:12:00 +0200

Un site web Plone est plus lourd et plus lent qu'un site développé (correctement) en PHP/MySQL. C'est un fait. Forcément, il n'y a pas toute la machinerie Zope derrière : gestion des droits, groupes et utilisateurs, moteur de worklows, etc... Un site développé en PHP/MySQL peut ne prendre que quelques lignes de code, alors que le même site fait avec Zope / Plone sera beaucoup plus gros, et de ce fait, gourmand en ressources.
Pour un petit site, la différence n'est pas énorme, par contre, si le site commence à être conséquent, optimiser son code devient crucial.

Pour optimiser un site Plone, on peut identifier trois phases :

Utiliser de bonnes pratiques de développement
Répartir la charge
Mettre en place un système de cache

Utiliser de bonnes pratiques de développement

Le portal_catalog

Lorsque l'on veut accéder à un objet, Zope doit "réveiller" cet objet, malheureusement, "réveiller" un objet est très coûteux. Cela l'est encore plus lorsque l'on veut afficher une liste et que chaque objet de cette liste est "réveillé".

Pour éviter de "réveiller" inutilement les objets, Plone dispose d'un catalogue : le portal_catalog.
Il permet d'indexer les objets (index) et de stocker certains champs des objets (metadata). Pour afficher une liste d'objets avec leur titre et un lien vers l'objet en lui même, plus besoin de "réveiller" tous les objets de la liste.
Les index vont vous servir lors des recherches dans le catalogue, alors que les metadata permettent d'accéder aux données de l'objet sans avoir à le "réveiller". Il est très simple de rajouter des index et des metadata dans le portal_catalog, que ce soit directement depuis la ZMI ou programmatiquement.

Au lieu de :
<a tal:attributes="href python:item.getObject().absolute_url()" tal:content="item.getObject().title_or_id">Mon Objet</a>

Préférez plutôt :
<a tal:attributes="href item/getURL" tal:content="item/Title">Mon objet</a>

Les scripts python

Lorsque vous créez des scripts python, au lieu de passer par la ZMI qui va faire plusieurs vérifications à chaque instructions, stockez les directement sur le File System, dans votre produit. Non seulement vous gagnerez en performance, mais en aussi en productivité. C'est beaucoup plus simple d'éditer un script python depuis son éditeur de texte favoris que depuis un formulaire web.

Une autre méthode est de créer un tool, ou d'utiliser les vues Zope 3 (via Five)

Répartir la charge

De base, nous avons une instance Zope avec sa ZODB (Zope Object Data Base). L'instance Zope reçoit les requêtes HTTP, effectue le rendu de la page et s'occupe de stocker les objets dans la ZODB.

image provenant de la présentation de Pilot Systems

Une installation simple

Une façon d'optimiser très simplement un site Plone est de mettre un serveur Apache en frontal devant l'instance Zope. Cette installation est suffisante pour les petits site à faible trafic. Par contre, il n'y a pas de tolérance de panne, et la montée en charge reste faible. Les performances du site ne sont que très faiblement accrues.

image provenant de la présentation de Pilot Systems

Répartition de charge avec ZEO

ZEO (Zope Enterprise Object), permet de diviser Zope en deux :

Une partie serveur pour stocker les données
Une partie cliente pour effectuer le rendu des pages et recevoir les requêtes HTTP.

image provenant de la présentation de Pilot Systems

L'avantage ici, est que l'on peut créer autant de clients que l'on veut. Le serveur ZEO peut être sur une machine physique différente des autres clients ZEO, et chaque client peut aussi être sur une machine physique différente.
Les clients sont tous relié au serveur ZEO. On peut répondre très facilement à une monté en charge : il suffit de rajouter des clients ZEO.

On peut dédier un client (ou plusieurs) pour l'administration du site, et ainsi améliorer les performances pour l'administration du site, sans dégrader les performances coté "publique".

Mettre en place un système de cache

La première solution est de mettre en place un serveur SQUID qui permet de gérer du cache. Il limite les requêtes vers les clients ZEO en retournant les pages en cache.

En complément de SQUID, Pound permet de répartir la charge entre les différents clients ZEO, (à noter que SQUID peut le faire aussi). Si un des clients ZEO n'est plus accessible, Pound redirige automatiquement les requêtes vers un autre client disponible.

image provenant de la présentation de Pilot Systems

Cette infrastructure est optimum, elle permet d'avoir un site complètement optimisé, avec très peu de requêtes traitées par Zope, le cache se situant en amont.
Si une panne survient sur un des clients ZEO, les autres prennent le relais, cela nous permet de réparer le client défectueux sans que les utilisateurs soient pénalisés.
Si l'audience du site augmente, il suffit de rajouter un ou plusieurs clients ZEO.

L'optimisation d'un site Plone passe par beaucoup d'étape, que ce soit au niveau de l'infrastructure comme du code produit. Heureusement, pour l'infrastructure, on peut commencer juste par avoir un apache en frontal, puis ajouter des clients ZEO et un SQUID si le besoin se fait ressentir.
Il est par contre plus fastidieux de revenir sur du code produit, il faut donc tout de suite adopter de bonnes pratiques de programmation.

Merci à Sylvain Viollon de Pilot Systems pour sa présentation lors des Solutions Linux 2007.