Compressons du XML dans la joie et la bonne humeur

Notre bande passante étant limitée, l'efficacité des communications est primordiale à une bonne montée en charge du serveur. Cependant, nous avons choisi pour des raisons de simplicité de coder nos communications en XML, qui est un format plutôt verbeux. C'est là que la magie de la compression se met en place!

L'on pourrait en théorie simplement compresser chaque message XML vers du binaire, et envoyer directement le binaire vers l'autre côté. Cependant, cette solution présente le désavantage de nécessiter un changement complet au niveau de la couche communication: il faut par exemple envoyer un en-tête avec la taille du paquet, et il est peu commode d'envoyer sur un même canal du xml compressé et non compressé.

La solution standard est de mettre le xml compressé à l'intérieur d'un autre message xml. Par exemple: "<adH><auth><login>mon login</login><password>mon password</password></auth></adh>" compressé pourra ressembler à ceci: "<adh>s0lM8bCzSSwtybCzyclPz8yzy83PUwCzbPQhA
jYFicXF5flFKWApGMdGHy5sow/Rr5+YkmEHAA</adh>"

Pour rester dans la norme, il est important que le message compressé soit composé de caractères ASCII, ce dont se moquent éperdument la plupart des systèmes de compression (au hasard, l'excellent zlib). Là encore, la solution standard est d'encoder le binaire en base 64, comme on le ferait pour un fichier attaché dans un e-mail. L'encodage en base 64 contrecarre malheureusement un peu la compression, puisqu'un message encodé prendra environ 4/3 de la taille de l'original, mais zlib derrière est très performant, ce qui permet de faire de très bons gains de bande passante quand les messages dépassent une certaine taille. Pour les messages plus petits, comme par exemple le message de login donné plus haut en exemple, le généré, comme vous pouvez le voir, est plus grand que le message non compressé. Dans ce cas, puisqu'il est si facile d'envoyer du xml compressé ou non, l'on gardera le message tel quel.



Le graphe suivant a été réalisé en compressant via zlib puis encodage base 64 un message XML de test, et en comparant la taille du message compressé à celle du message original. L'on voit bien que le taux devient intéressant (inférieur à 1) à partir de 200 octets. C'est probablement dans cette zone qu'il faut définir le seuil à partir duquel l'on compressera la trame.

Il est également intéressant de noter à quel point la compression est efficace pour des fichiers plus gros: une trame de 1500 octets sera compressée à 358 octets!