Tests de dimensionnement matériel, logiciel et réseau
Transcription
Tests de dimensionnement matériel, logiciel et réseau
Tests de dimensionnement matériel, logiciel et réseau Raymond Rivest Conseiller, spécialiste de test, CRIM Centre de tests du logiciel [email protected] Que sont les tests de dimensionnement ? À quoi servent-ils ? Et pourquoi sont-ils importants ? Dans cette série de deux articles, nous examinerons les différents aspects des tests de dimensionnement, pour en comprendre autant la nature que le besoin qu'ils comblent. Dans le premier article, nous examinerons le contexte général du dimensionnement, alors que nous aborderons la méthode plus en détails dans le deuxième article. 1er article Le contexte général Déployer une nouvelle application sur le Web équivaut à introduire une nouvelle espèce dans un écosystème déjà lourdement chargé. La nouvelle espèce sera-t-elle une proie ou un prédateur? À quel niveau de la chaîne alimentaire se retrouvera-t-elle, une fois déployée? Il existe déjà une multitude d’applications déjà en fonction sur le Web. Certaines d'entre-elles sont très utilisées, d’autres peu. Quelques-unes sont très performantes, d’autres moins. Certaines sont lourdes, d’autres non. Certains ISP1 privilégient le HTML2 des fureteurs Web, d’autres le courriel ou bien les FTP3. Tous ces éléments représentent l’écosystème qu’est le Web. Votre application devient une nouvelle espèce. Dans l’écosystème qu’est votre réseau local, les ressources naturelles sont abondantes. Même à 10 Mbps, une nouvelle application sera relativement performante si votre réseau est le moindrement en santé. Mais sur le Web, les ressources sont plus limitées, car elles sont partagées par un plus grand nombre d’espèces. Les objectifs L’objectif des tests de dimensionnement est de déterminer la structure matérielle et logiciel optimale, afin que le système à déployer réponde adéquatement lorsqu’il est sollicité. Il doit fournir les temps-réponses raisonnables. Ces tests peuvent aussi fournir des pistes d’amélioration quant à la façon d'utiliser les protocoles de communications. Certaines technologies sont tellement récentes qu’il faut parfois beaucoup de temps et d’expérimentation afin de bien les maîtriser. Le maillon le plus faible En réseautique, le maillon le plus faible est généralement le goulot d’étranglement. Une fois celui-ci saturé, le système ne pourra fournir de meilleures performances sans changement. Le principe derrière le dimensionnement est de déterminer à l’avance l’endroit où se situera ce goulot. Une fois le goulot identifié, on peut ajuster le système pour déplacer ce goulot et obtenir ainsi de meilleures performances. 1 ISP : Internet Service Provider (fournisseur de services Internet). HTML : Hyper Text Markup Language : langage composant les pages Web. 3 FTP : File Transfert Protocol : protocole de transfert de fichier. 2 Il s’agit parfois simplement de modifier la structure du code, de changer quelques paramètres de configuration d’un serveur ou de modifier l’infrastructure matérielle aux endroits stratégiques pour obtenir un gain ou une stabilité accrue des performances. Entre un LAN et un WAN Il faut bien comprendre la distinction entre un LAN4 et un WAN5. Un réseau interne (LAN) ne souffre pas du délai de latence (délai de transmission), le circuit de 100 Mbps étant généralement fermé. Dans un WAN, ce sont des milliers de systèmes qui se croisent sur de grandes distances, avec plusieurs points de redistribution. La ligne n’est plus droite et directe. Un autre facteur majeur en WAN est les règles de routages. Chaque ISP gère à sa façon la priorisation des communications réseaux. Comme ces priorités varient d’un ISP à l’autre, des variations de performance en résultent entre les différents points qui constituent la route entre deux points d’un réseau. Les protocoles et l’Internet Les protocoles sont conçus soit pour les réseaux internes, soit pour les réseaux à grande surface. Certains servent à la gestion du réseau interne (tel NETBEUI) et supportent mal les délais de transmission induits par les réseaux à grande surface. En effet, certains protocoles ont besoin d’un temps de réponse très rapide pour éviter d’interrompre la transmission. D’autres protocoles génèrent beaucoup d’échanges d’informations, causant énormément d’aller-retour des communications. Sur un réseau local, à 100 Mbps, ces aller-retour sont négligeables, puisque l'espace est suffisant et qu’il n’y a pas de délais de transmission. Mais dans un WAN, le délai de transmission retarde chacun des aller-retour, ce qui a pour effet de ralentir les communications au point de les rendre déficientes. La vitesse des liens Si on compare un réseau à un système d’aqueduc, on comprend mieux la distinction entre la vitesse d’un lien et le débit en entrée et sortie disponible, par rapport à la taille des conduits, à leur pression et au nombre d’habitations à desservir. Tout comme un réseau d’aqueduc, le nombre d'utilisateurs influence la disponibilité de pression (équivalent au débit disponible). Afin d’augmenter le débit, on intensifie la pression ou on grossit la taille du conduit. Dans le cas d’un lien Internet, on ne peut augmenter le débit global. Il faut donc optimiser et prioriser les accès. La vitesse du lien n'est pas seule en cause. Le trajet entre deux points compte aussi pour beaucoup. Malgré un lien à 1544 Kbps, s’il y a un lien plus étroit sur le trajet, ce dernier deviendra votre maximum. Il faut aussi tenir compte des autres éléments de réseau tels les coupe-feux, serveurs de DNS, proxy qui effectuent une partie du traitement en cours de route. Les coûts d’une contre-performance Un système trop lent ou qui ne répond plus représente des pertes d’exploitation qui peuvent s’avérer importantes. Si votre revenu dépend de la fiabilité de votre portail Web, vous avez tout intérêt à ce qu’il soit opérationnel en tout temps ! Un article intéressant sur des pertes occasionnées par les pannes de système est disponible à http://www.internetwk.com/lead/lead073099.htm. Dans le prochain article, nous examinerons de plus près les aspects techniques du dimensionnement. 4 5 LAN : Local Area Network : réseau local. WAN : Wide Area Network : réseau à grande surface tel l’Internet. Tests de dimensionnement matériel, logiciel et réseau Raymond Rivest Conseiller, spécialiste de test, CRIM Centre de tests du logiciel [email protected] 2ième article Dans ce deuxième article, nous examinerons les aspects techniques du dimensionnement. Tests de charge, de stress et de configuration Afin de déterminer les goulots d’étranglement et la stabilité du système, des tests de charge et de stress sont exécutés. La principale différence entre ces deux types de test est la suivante : • Un test de charge comporte un scénario de base, pour lequel le volume de transaction et d’usager sera augmenté de manière graduelle. • Un test de stress consiste à exécuter un scénario de charge maximale du système sur une période maximale. Pour le test de charge, il s’agit de déterminer à quel moment le système ne sera plus conforme aux performances requises ou que des erreurs surviendront. Pour le test de stress, il s’agit de déterminer combien de temps le système peut supporter la charge maximale sans entraîner de corruption de données ou cesser complètement de fonctionner. Une fois les goulots identifiés, on procède au dimensionnement du système en fonction des objectifs de performance requis. Les composantes du système seront ajustées, ainsi que les configurations, de façon à obtenir le meilleur rendement. Le contexte de déploiement Le contexte de déploiement est l’ensemble des composantes du réseau et du système dans lequel il devra évoluer. Ce contexte comporte aussi plusieurs autres système déjà existants sur le réseau et sur les serveurs des clients. Il contient aussi les flux de trafic dus aux horaires de travail. Le contexte est en quelque sorte l’écosystème dans lequel la nouvelle espèce doit plonger. Selon les besoins et la localisation, l’infrastructure matérielle et réseau peut varier et ne pas représenter des conditions optimales. Il faut donc prédire comment se comportera le système dans un autre milieu. Le contexte d’utilisation Les divers types d’utilisateur emploieront le système de façon distincte et selon des horaires différents. Une bonne évaluation des caractéristiques d’utilisation permettra donc un meilleur dimensionnement. On appelle souvent ce contexte la «logique d’affaire». On doit aussi déterminer, selon le type d’utilisateur, les temps de réponses requis ou acceptables. Dans certain type d’applications, des temps de réponse trop longs peuvent s’avérer critiques. Il faut aussi tenir compte de la durée de vie de l’information. Dans le cas d’une base de données, la durée de vie a une influence sur sa taille et sur la vitesse d'accès à l’information, si cette information date de plusieurs années. L’estimation de volume Il faut également estimer le volume que devra supporter le système afin de maintenir le niveau de performance requis. Il faut aussi prendre en compte l’augmentation possible du volume et prévoir ainsi la croissance du système. Une bonne évaluation de la croissance du système permet d'envisager la capacité des systèmes, leur durée de vie ainsi que les périodes de maintenance requises. Ces informations détermineront les caractéristiques des machines, des liens et le type d’infrastructure matériel exigés afin d’assurer le niveau de performance et la qualité de service. Le poids par usager L’objectif final est de déterminer les besoins matériels et réseau par usager pour ainsi obtenir le meilleur rendement du système, selon le nombre d’usagers et les caractéristiques de performance prédéfinies. Le poids d’un usager est donc calculé en termes de débit en entrée et sortie par période de pointe ainsi qu’en transactions/minute sur le système. On évalue aussi le pourcentage de mémoire et de temps de processeur par usager sur le serveur. Les clients/serveurs, multi-agents et déportés Selon le type de système, la complexité et la quantité des tests peuvent varier. Dans un contexte de client/serveur, l’accès simultané aux informations est l'élément primordial, alors que dans un système multi-agents, la synchronisation des composantes devient critique. Une technologie en émergence est le modèle d’écran déporté de Citrix Metaframe ou Microsoft Terminal Server. Ces systèmes réduisent énormément les besoins en capacité réseau. L'aspect client est moins exigeant tant de la machine que de la connexion réseau. Par ailleurs, le traitement et le stockage sont généralement centralisés dans un réseau local à accès commuté6. Un parc de serveurs soutient plusieurs utilisateurs concurrents. Dans ce type de technologie, il est important de prévoir la répartition des charges par usager sur les serveurs (load balancing). Si cette répartition est mal calculée, les performances seront médiocres. En conclusion En conclusion, il vaut mieux se préparer adéquatement avant de mettre un nouveau service en ligne. Trop souvent, on sous-estime la charge attendue ou au contraire on surestime la capacité des liens ou des serveurs. Un système en panne dès sa mise en disponibilité peut réduire à néant des milliers de dollars d’investissement de développement. Cela peut aussi représenter plusieurs milliers de dollars en ventes perdues. À vous de juger si le jeu en vaut la chandelle ! Quelques références sur le sujet. Le FAQ du groupe de discussion comp.software.testing sur le test logiciel : http://www.crim.ca/ctl/cst.FAQ.html Le site de Webperformance Inc., un fournisseur d’outil de test de performance : http://www.webperformanceinc.com/ Le site de United Device, avec une liste des questions fréquemment posées sur les tests de performance : http://members.ud.com/projects/web_test/faq_proj.htm 6 L' accès commuté est un réseau local utilisant un commutateur (switch) plutôt qu’un concentrateur (hub).