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] 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é1. 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 1 L' accès commuté est un réseau local utilisant un commutateur (switch) plutôt qu’un concentrateur (hub).