Etude de cas – Optimisation applicative de Office 2013

Si vous n’avez jamais entendu parler de Riverbed et de sa truite aux oeufs d’or, je vous invite à jeter un oeil sur la page descriptive du produit disponible sur le site de Riverbed.
Ou mieux encore, l’article rédigé par Christophe sur l’accélération applicative.
Pour les plus pressés d’entre vous, en quelques mots : SteelHead est une solution d’optimisation réseau qui s’articule autour de deux axes majeurs : l’optimisation et la qualité de service des flux WAN.

Cet article a pour but de vous illustrer ces deux axes au travers d’un scénario très commun au sein des entreprises : la lecture/écriture de fichiers Office en accès distant et situé dans un serveur de fichiers au datacenter.

Comme vous pouvez le constater, il est réduit au minimum afin d’en faciliter sa visibilité :

Afin de mettre en évidence les avantages liés à l’accélération applicative, je vais donc appliquer le scénario suivant depuis le PC client :

Le fichier test est une présentation commerciale utilisée par ISIS Performance au format .pptx et pesant 14,4 Mo. Pour mieux visualiser les échanges réseau, l’utilisateur du site distant dispose de la totalité de la bande passante du lien de 1 Mega.

Voici notre scénario vu du SteelHead côté client :

1. La simple ouverture de l’explorateur de fichiers Windows a généré un petit pic de charge occupant 25% de la bande disponible pendant 2 secondes.
2. Puis l’ouverture du fichier a monopolisé 100% de la bande passante WAN disponible pendant … 1 minute et 55 secondes ! Rien n’est optimisé.
3. La fermeture du fichier n’a engendré qu’un léger trafic côté WAN, à peine visible sur notre graphique : le SteelHead a commencé à optimiser les échanges TCP et SMBv2.
4. La seconde ouverture de ce même fichier n’a quasiment généré aucun trafic sur le WAN, c’est le SteelHead qui a libéré la presque intégralité des données via son système de cache. Temps d’attente avant de visualiser les slides : 3 secondes.
   NB : On constate un second pic sur le LAN qui correspond au téléchargement du reste du contenu du document, poussé par le SteelHead en tâche de fond.
5. Pendant la modification du fichier, rien ne se passe côté réseau.
6. J’enregistre et je ferme le document. Du point de vue de l’utilisateur, j’ai compté 5 secondes avant la fermeture du document : c’est le temps d’enregistrement du delta de modification. Puis, là encore, on s’aperçoit que le flux SMBv2 continue pendant une vingtaine de secondes après la fermeture du fichier, essentiellement côté LAN grâce à la réduction de données.

Sur ce scénario d’utilisation, SteelHead a réduit d’environ 87% les données, pour un total de 218,8 Mo économisés sur la bande passante du VPN !