Faire une évaluation technico-financière de GZip, BZip2 et XZ

Cela fait un petit moment que je vois des fichiers compressés avec XZ, ce dernier est un format de compression basé sur l’algorithme LZMA2.

D’après ce que l’on peut voir sur Internet, il est très efficace pour la compression. Il est d’ailleurs utilisé dans certaines distributions Linux pour réduire la compression d’une archive afin que l’ensemble du live cd tienne dans le cdrom ou tout simplement pour réduire au maximum un paquetage (ici l’annonce du support dans Debian).

La question à 2 centimes qui se pose, c’est : est-ce que je vais remplacer le GZ par le XZ ?

Pour y répondre, je propose d’utiliser la méthode « évaluation technico-financière » que l’on retrouve souvent dans les appels d’offres publiques ici au Maroc.

Cette méthode analyse chaque offre commerciale selon deux axes en attribuant une note technique et une note financière à chaque offre en fonction de l’offre la moins chère, le prix de l’offre courante et sa note technique, puis calcule une note technico-financière selon un rapport 60% technique et 40% financier.

Pour cette évaluation, nous allons considérer les trois « répondants » suivants : GZip, BZip2 et XZ. Ils seront tous couplés avec l’utilitaire tar pour l’empaquetage des fichiers et répertoires.

  • L’axe technique, sera le taux de réduction (de compression), c’est-à-dire de combien, en pourcentage, a été réduit l’orignal.
  • L’axe financier sera mesuré avec le temps de compression mesuré avec l’utilitaire time (valeur real). Ne pas oublier le vieil adage : le temps c’est de l’argent…

Continuer la lecture de Faire une évaluation technico-financière de GZip, BZip2 et XZ

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 ? Continuer la lecture de Compression HTTP, ou comment réduire le temps réseau dans les performances d’une application