wOueb by Romain DECKER / Another IT Guy Blog

Vous aimez jouer avec les paramètres de votre serveur web (Apache, lighttpd, Nginx, etc.) ou avec votre code source, mais comment savoir si cela a un impact négatif ou positif sur les performances ?

Avant d’entrer dans le vif du sujet, je tenais à préciser que le benchmarking d’une application web ou d’un serveur est une tâche complexe : il ne faut pas penser arriver avec une commande toute prête qui vous donnera un chiffre magique. Il faut comprendre où peuvent se situer les goulots d’étranglements, comprendre le design global, etc.

La fondation Apache a intégré un outil dans son programme : « Apache HTTP server benchmarking tool« , plus communément appelé « Apachebench » (ou encore « ab« ), qui vous permet de savoir combien de requêtes par seconde votre installation est capable de fournir.

Ce qu’il est possible de faire avec Apachebench : simuler du traffic en générant des requêtes HTTP.

Ce qu’il n’est pas possible de faire avec Apachebench : simuler le comportement d’un utilisateur qui visite un site/une application.

Pour installer Apachebench sur Debian/Ubuntu :

$ sudo aptitude install apache2-utils

Pour installer Apachebench sur Red Hat / CentOS : le programme « ab » est installé avec Apache. Pour ceux qui n’ont pas Apache installé :

# yum install httpd

La documentation, et sinon un « man ab » permettra de vous donner rapidement les différents paramètres. Par exemple, pour tester mon blog j’utilise les paramètres suivants :

# ab -t30 -c5 http://www.woueb.net/

• -t : représente la durée du test, soit 30 secondes
• -c : indique le nombre de requêtes concurrentes (simultanées) à utiliser

Voici le résultat sur mon serveur : la valeur la plus importante (entourée en rouge) est le nombre de requêtes par seconde qu’à pu supporter le serveur.

Dans cet exemple, Apachebench va uniquement charger le contenu de la page d’accueil de mon blog (textes, contenus et code html) sans appels extérieurs (images, CSS, Javascript, etc.). J’insiste sur le faire que ce n’est pas représentatif de l’utilisation d’un visiteur normal.

En précisant le paramètre « -w« , le résultat est exporté dans un tableau HTML.

Résultat d'Apache Benchmark pour woueb.net en HTML

Sinon, un « man ab » vous donnera également un aperçu de la documentation.

Deux types de tests :

• test en local : permet de tester le nombre maximum de requêtes par secondes que le système peut fournir, sans tenir compte de la bande passante.
• test à partir d’un serveur distant : pour tester en « conditions réelles » avec l’influence de la bande passante. Dans ce cas, il est intéressant de prévoir plusieurs tests simultanés et de tenir compte de la bande passante sortante du serveur à partir duquel la commande est lancée.

Quelques conseils :

• ayez une bonne alimentation,
• essayez d’avoir une bonne bande passante entre le serveur testé et le serveur destination,
• relevez la charge de votre serveur web avant, pendant et après le test (CPU, Ram, nombre de processus, load, etc.),
• testez plusieurs pages de votre site/application,
• ne vous contentez pas d’un seul test : faites plusieurs tests d’affilé, ou à différents moments de la journée, et calculez les moyennes.

ApacheBench est donc un outil basique mais qui permet notamment de se rendre compte d’une augmentation (ou d’une diminution) de performances suite à une modification de code, de configuration, de rajout matériel, etc.

Si vous utilisez Microsoft Visio pour faire des schémas, il est utile d’avoir les formes de tel ou tel matériel, serveur, élément réseau, etc.

Vous trouverez un grand nombre de formes (« shapes ») officielles et gratuites sur VisioCafe : Dell, HP, IBM, Cisco, etc.

Je parlais vendredi de mod_pagespeed, et en consultant les paramètres, j’ai vu qu’il était possible d’afficher les statistiques d’utilisation, sous la même forme que le server-status d’Apache.

Dans le fichier de configuration pagespeed.conf, on retrouve la chose suivante :

< Location /mod_pagespeed_statistics >
Order allow,deny
# You may insert other « Allow from » lines to add hosts you want to
# allow to look at generated statistics. Another possibility is
# to comment out the « Order » and « Allow » options from the config
# file, to allow any client that can reach your server to examine
# statistics. This might be appropriate in an experimental setup or
# if the Apache server is protected by a reverse proxy that will
# filter URLs in some fashion.
Allow from localhost
SetHandler mod_pagespeed_statistics
< /Location >

Il suffit d’autoriser la bonne adresse IP, le bon réseau, ou tout le monde, puis de se connecter avec un navigateur à l’adresse http://serveur.domaine/mod_pagespeed_statistics.

Voici le résultat pour mon blog (consulté avec Lynx, en local sur mon serveur) :

Statistiques mod_pagespeed

En rouge, on peut voir entres autres une estimation du nombre de bytes (octets) économisés :

• ~ 2 Ko économisés pour le CSS,
• ~ 1,9 Mo économisés pour les images,
• ~ 70 Ko économisés pour le javascript.

L’extension PageSpeed pour Firefox/Firebug permet d’évaluer les performances des pages web et prodigue des conseils pour optimiser la vitesse de celles-ci.

Cette semaine, c’est un module pour Apache, mod_pagespeed, qui vient compléter ce panel d’outils. Mis à disposition par Google (gratuitement, sous licence Apache), il est encore en version beta mais permet déjà des résultats visibles.

Comme je suis curieux, je l’ai installé sur mon serveur (qui était déjà optimisé depuis quelques semaines).

NB : pour l’installer en toute sécurité, j’ai fait un snapshot de mon serveur dédié (merci VMware ^^), au cas où !

Je grapille 1% au test Page Speed sur GTmetrix, notamment avec quelques petites améliorations dans les points suivants :

• Serve static content from a cookieless domain,
• Optimize images,
• Minify HTML,
• etc.

Cependant, sur certains points les performances diminuent : comme quoi, la solution magique n’existe pas, et simplement activer un module sur votre serveur ne fera pas forcément des miracles si vos applications n’en sont pas conscientes.

• Un peu de lecture : http://code.google.com/speed/page-speed/docs/module.html
• Pour télécharger mod_pagespeed : http://code.google.com/speed/page-speed/download.html
• Pour tester mod_pagespeed : http://www.modpagespeed.com/

Pour la configuration, vous trouverez des informations par ici, ou ailleurs sur l’Internet Mondial (qui va être beaucoup plus rapide maintenant) !

La news est sur le blog Webmaster Central Blog.

En faisant le tour des outils de performances de pages/sites web pour mon article sur Pingdom Full Page Test, j’ai découvert GTmetrix.

GTmetrix analyse les pages web et :

• décortique la vitesse de chargement par rapport aux objets chargés,
• assigne une note et donne des conseils pour optimiser le temps de chargement,
• permet de comparer par rapport à une autre page,
• etc.

J’ai fait le test une fois que j’avais fini d’optimiser mon blog, et le résultat est plutôt bon.

Le rapport de performance présente les informations de façon séquentielle, en commençant par les mauvais points.

Vous pouvez également consulter le temps de chargement et la taille de chaque objet :

Il vous est possible d’enregistrer un test et de le planifier de façon récurrente.

Le fait d’enregistrer ses rapports pour les faire tourner à intervalle régulier permet d’avoir une historisation automatique des résultats.

Pour résumer, GTmetrix est un outil très simple d’utilisation, très concret dans son utilisation, et plutôt bien conçu : je le conseille vivement !

Pour ceux qui utilisent plusieurs postes comme moi, un problème s’est posé pendant longtemps : la synchronisation des favoris (bookmarks). Bien sûr, il existait des outils qui synchronisait par exemple via del.icio.us mais rien me convenant vraiment.

J’avais adopté Firefox depuis longtemps (depuis la version 0.5 si je ne m’abuse), et quand Xmarks est apparu en 2006 j’avais enfin trouvé ce qu’il me fallait (au départ, le produit s’appelait Foxmarks) : synchronisation des bookmarks, des passwords, le tout en multi-poste avec une reprise sur un serveur, le bonheur !

L’autre grand avantage de Xmarks est qu’il fonctionne indépendamment du navigateur : il fonctionne aussi bien sur Firefox que sur Safari, Internet Explorer ou encore Google Chrome.

Cependant, comme tous les enregistrés à Xmarks, j’ai reçu un mail en début de semaine pour m’informer que le service allait fermer à la fin de l’année.

C’est dans ce contexte là que je me suis penché sur Firefox Sync : j’avais testé Weave, qui était une approche « béta » de ce service, mais sans conviction…

(suite…)