Compression HTTP, ou comment réduire le temps réseau dans les performances d’une application

Avec JMeter on peut faire des tirs de performances (et d’autres choses) pour une application Web. Pour qu’une application soit performante, il est préférable qu’elle soit développée judicieusement, mais également qu’elle s’exécute sur un environnement performant. Dans ce dernier, il ne faut pas négliger la composante réseau qui peut souvent devenir un goulet d’étranglement au niveau de l’utilisateur.

En effet, vous allez développer une application hyper véloce, la faire fonctionner sur des serveurs hyper-rapides, mais votre utilisateur au bout de la ligne vous dit que c’est lent…

Vous (re)faites vos tir de charges, vous mesurez les performances, c’est excellent… sur votre réseau local. Vous placez un injecteur chez votre utilisateur final, et là c’est la surprise… c’est lent.

Le diagnostic est rapide : trop d’octets à transférer pour afficher un écran, avec une bande passante trop petite donc lenteurs. Et impossible d’augmenter la bande passante. Que faire ?

Bien entendu, il est possible (et il faut) optimiser ses pages HTML / XML, le taux de compression des images, etc. de son application. Tout ceci dans l’objectif de réduire le poids général en octets d’un écran.

Il y a aussi une astuce tout simple. La compression des données transitant entre le serveur Web et l’utilisateur final à travers la compression HTTP.

Cette compression basée sur l’algorithme des fichiers ZIP, est effectuée au niveau du serveur Web qui compresse à la volée les données à transmettre. Ensuite la décompression est assurée du coté des navigateurs Web.

Pour que cela marche, il faut bien entendu un navigateur récent (au moins IE 4.0, Firefox 1.0, etc) mais c’est le cas de tout le monde. Pour le serveur Web, il lui aussi doit être relativement récent (au moins IIS 5.0, Apache 2.x, etc). Il y a ensuite une configuration à faire à son niveau pour activer la compression.

Pour Apache, par exemple, c’est le module mod_deflate (et aussi mod_gzip) qui assure cette fonction. On peut ainsi ajouter dans son virtual host, les lignes suivantes (tirées que la documentation Apache) pour compresser tous les flux sauf les images.

# Insert filter

SetOutputFilter DEFLATE

# Netscape 4.x has some problems...

BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems

BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images

SetEnvIfNoCase Request_URI \

\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Après le redémarrage du serveur Apache, le résultat donne, par exemple, pour la page d’accueil de ce blog (juste le contenu HTML) :

• Avant, sans compression : 50 198 octets transférés
• Après, avec compression : 11 903 octets transférés

Soit une diminution de 38 ko (-76%) à transférer sur le réseau ! C’est pas mal comme optimisation ? Et en plus c’est transparent pour tout le monde.

Ainsi, avec l’activation de la compression, les bons temps de réponses de son application ne seront pas masqués par les temps de transferts réseaux importants, et l’utilisateur au bout trouvera l’application rapide.

[Quelques pointeurs]

• Apache – module mod_deflate
• Wiki : la compression HTTP
• La compression HTTP par son inventeur

./