J'aimerais m'étendre sur le récent blog de Paul "Vos tests de pré-production sont-ils efficaces ? Paul a abordé l'utilisation du CPU et les chemins de code, mais il y a un autre aspect très important de nombreuses applications : l'utilisation du réseau. De nombreuses applications sont testées dans un environnement LAN avec des latences de l'ordre de la sous-milliseconde et une bande passante d'au moins 100 mbps. Elles sont ensuite déployées pour être utilisées sur un réseau étendu (WAN) avec des bandes passantes plus petites et des latences beaucoup plus élevées. Les résultats peuvent être catastrophiques.
Bien que les tests dans un environnement LAN permettent de découvrir la plupart des bogues liés au réseau, il peut y avoir des bogues liés à des paquets déposés ou à une segmentation inattendue (TCP ne maintient pas les limites de vos messages) que vous êtes moins susceptible de voir dans un environnement LAN. Il est également beaucoup moins probable que vous remarquiez une conception moins qu'optimale dans un environnement LAN rapide que dans un environnement WAN lent. Il est donc très important de tester toute application basée sur un réseau dans l'environnement réseau le plus défavorable, avec une faible bande passante, des latences élevées et sans oublier les taux de perte de paquets.
Il y a deux façons de le faire.
La première consiste à utiliser l'environnement réel. Placez le serveur (ou le client) sur un hôte du réseau et voyez comment il fonctionne. Cela présente l'avantage d'utiliser l'infrastructure réelle. L'inconvénient est que vous n'avez aucun contrôle sur l'environnement, ce qui est essentiel lorsque vous essayez de reproduire un problème ou de tester une solution à un bogue.
La seconde consiste à utiliser un simulateur WAN. Il existe des simulateurs matériels et logiciels uniquement, commerciaux et open source (gratuits). L'avantage ici est que vous avez un contrôle total sur la latence, le taux de chute des paquets et d'autres paramètres du réseau, et que vous n'avez pas à impliquer d'autres groupes (c'est-à-dire mettre votre logiciel sur le système de quelqu'un d'autre). L'inconvénient est le coût et une courbe d'apprentissage. Même si vous utilisez des logiciels libres, vous devez fournir un système (généralement une variante d'Unix) pour le faire fonctionner et apprendre à l'utiliser. Il y a plusieurs années, j'ai écrit un tutoriel sur Dummynet. À l'époque, c'était l'un des rares simulateurs gratuits disponibles. Aujourd'hui, il y en a beaucoup plus, il suffit de googler "wan simulator".
Sur la base de mon expérience dans l'étude des problèmes de performances et de défaillance des applications, je pense que ce type de test sera plus que rentable en réduisant les arrêts de production dus aux bogues et en augmentant les performances de l'application et de ses utilisateurs.
Entreprise