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).

Documents pareils