L’importance du test

principales
briques. On réduira ainsi le risque de
capacité insuffisante parce que le pilote
donnera des données de dimensionnement
valables. Par ailleurs, les
planificateurs devront se référer à  des
benchmarks certifiés et publiés comme
guides de l’évolutivité de briques
de plus grande taille, impossibles à  évaluer
dans le domaine limité d’un pilote.
Dans la mesure du possible, les
concepteurs devront demander aux fabricants
des références de sites où
d’autres clients emploient un matériel
similaire sous une charge comparable.
L’un des tests les plus importants
est une simulation de bout en bout en condition de charge. Des générateurs
de charge comme Mercury Load-
Runner (http://www.mercury.com) ou
Rational Performance Studio (http://
www.rational.com) offrent des possibilités
de génération de charge HTML basée
sur le Web, capables de simuler des
milliers d’utilisateurs navigateurs en
temps réel. Lors d’un test chez IBM,
nous avons pu simuler environ 1 500
utilisateurs par PC agent (nous utilisions
des PC avec des processeurs 1
GHz Pentium III double, 2 Go de mémoire
principale et des disques durs
de 30 Go). Une configuration de 10 PC
agent et d’un contrôleur pouvait simuler
en théorie 15 000 utilisateurs.
Un test digne de ce nom doit porter
sur plusieurs facteurs : utilisation de
la CPU, utilisation des bras de disque,
temps de réponse utilisateur moyen,
utilisation du réseau, hits par seconde,
transactions par heure, ainsi que les
moyennes et pointes de trafic. Les
temps de réponse doivent être évalués
dans divers points de test. Ainsi, dans
les tests effectués chez IBM, nous
avons constaté un temps de réponse
moyen de 0,55 seconde en utilisant la
configuration qu’illustre la figure 2.
(Ces temps de réponse n’incluent pas
le temps nécessaire pour traverser
Internet ni l’utilisation de fonctions de
sécurité comme SSL. Mais, le test doit
inclure l’utilisation de ce genre de
fonctions dans un projet pilote quand
on planifie un déploiement réel.)