Comparaison des protocoles de compression

Compress is Green !

La compression des informations sans perte a de nouveau le vent en poupe en période de prise de conscience écologique.
Sur la même vague que Google Wave économique en espace de stockage et en bande passante ou du protocole Google SPDY censé doubler la vitesse du Web, les systèmes de compression historiques permettent de diminuer l'espace de stockage, la bande passante consommée pour échanger les informations, la durée de traitement.

Cet article fait un état des lieux sur l'efficacité des systèmes de compression les plus répandus.

Compresser, pour quoi faire ?

L'échange d'informations compressées se fait en 3 étapes : compression, échange des informations, décompression.
Suivant les protocoles de compression, les durées de ces étapes et le volume de donnée varie.
En fonction de vos besoins, le protocole idéal pourra être différent. Ainsi, pour des opérations de sauvegarde, le taux de compression est le facteur clé. Pour un système de communication en ligne type VOIP, la durée de compression et de décompression est le facteur clé. Enfin pour un système en ligne centralisé type serveur Web, la durée de compression sur votre serveur est le facteur clé.

Protocole de test

L'objectif est comparer les taux de compression, les temps nécessaire pour compresser et décompresser, avec un réglage optimisé pour la vitesse, le réglage par défaut et un réglage optimisé pour la taille de l'archive.
Le fichier de référence est une archive non compressée tar qui mélange des contenus textes et binaires. La taille de ce fichier est 1.1Go.

Les protocoles testés sont les formats zip, le format gzip, le format bzip2 et le format 7z.

Les résultats

Conclusion

Pour l'archivage d'information et les traitements batch de gros volumes d'informations, la compression 7z fait la différence avec un taux de compression nettement supérieur aux autres formats sans paramètre avancé. En contre partie, la compression consomme 5 fois plus de CPU ; totalement inadapté au protocole HTTP.

Pour la communication en ligne, l'ancien format de compression gzip datant de 1991 est plus rapide - économe en CPU - et réduit significativement la taille des données de 50% en moyenne, 90% pour les données textes. Il n'est donc pas surprenant que cet algorithme soit toujours utilisé presque 20 ans plus tard dans le module de compression de données mod_deflate des serveurs Web Apache2.