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

Documents pareils