Positionnement

Vous avez achetée une nouvelle plateforme pour votre base de données de production. Vous allez migrer en 11gR2.
Nouveau serveur, nouvelle baie de stockage, nouvelle version de base de données  … bref suffisamment de changements pour réaliser une migration « à blanc » et valider que votre applicatif fonctionne.
Seulement voila, vous n’avez pas d’outil de test de montée en charge. Pas de licence « Real Application Testing » prévue dans vos budgets (et ce malgré un ROI démontrable), pas d’outil de type « LoadRunner » (très compliqué, moins intéressant et beaucoup plus cher que RAT de toute façon) non plus.
Plutôt que de faire « l’impasse » sur les tests de montée en charge et de s’en remettre à la capacité de votre constructeur à comprendre vos besoins, je vous propose de réaliser un test de montée en charge « à minima » qui nous permettra de valider le comportement de cette nouvelle plateforme lorsqu’elle est soumise à une charge.

Solution proposée

Nous allons utiliser un outil gratuit nommé « SwingBench » depuis un poste de travail quelconque (notre « laptop » sous « Windows 7 »). Des configurations de « Swingbench » plus élaborées avec plusieurs « injecteurs » pilotés depuis une console centrale sont possibles, mais nous n’aborderons pas ce type d’architecture de « testing » ici.
Le principe est de « charger » des données « type » dans votre base de données et de lancer des scénarios « type ».
Pour cela 2  « Wizard » principaux existent et permettent de créer des données correspondant aux 2 scénarios suivants :

Choisissez le scénario le plus « proche » de votre applicatif, les pourcentages peuvent être modifiés par la suite dans l’interface d’utilisation.
Pour notre démonstration, nous avons choisi « Order Entry ».
 

Installation

Outil

Téléchargement ici : http://dominicgiles.com/downloads.html
Son installation est simple : on « dézippe » le fichier « swingbench » et on modifie uniquement le fichier de configuration « swingbench.env » ou « swingbenchenv.bat » pour « Windows » avec vos valeurs « ORACLE_HOME », « JAVA_HOME » et « SWINGHOME ».

Données

Vous devez évidemment disposer d’une base de données dans la version de votre choix (11gR2 de préférence).
Il faut créer un « tablespace » dans la base de données pour héberger les données fournies par l’outil :

Puis lancer le script « oewizard.bat », depuis le sous-répertoire « winbin » et renseigner les informations de connexion à votre base de données (un « RAC » ici) puis indiquer le volume de données à utiliser (à comparer au volume de votre base de données à migrer, se référer à la taille du « tablespace » qui est 3 fois celle du volume choisi).

Renseigner les informations de connexion à votre base de données (un « RAC » ici) :

Ici nous indiquons le volume de données à utiliser (à comparer au volume de votre base de données à migrer, se référer à la taille du « tablespace » qui est 3 fois celle du volume choisi) :

Utilisation

Lancement

Il faut lancer tout simplement « swingbench.bat » depuis le sous-répertoire « winbin ».

Dans la partie en haut à gauche de l’interface vous renseignez les informations de connexion au schéma que vous avez crée précédemment.
Dans la partie en haut à droite vous pouvez modifier les proportions de « SELECT-INSERT-UPDATE-DELETE ».
Dans la partie en bas à gauche vous pouvez indiquer le nombre de sessions concurrentes et la durée (« BenchMark run time ») de votre test.
Les résultats seront affichés dans la partie en bas à droite.

Principes

2 approches :

• Soit vous avez une idée précise de vos objectifs en termes de nombre de transactions par seconde à être en capacité de fournir, latence maximale tolérée, nombre d’utilisateurs concurrents
• Soit vous voulez « savoir » ce que peut « encaisser » votre plateforme et déterminer par exemple combien d’applications vous pourrez héberger demain

En fonction de vos objectifs donc, nous allons configurer l’outil en faisant varier le nombre d’utilisateurs concurrents qui est la seule variable de l’interface graphique utilisable.

Résultat

Voici un exemple de résultat avec 200 utilisateurs concurrents : on note une moyenne de 187 transactions par secondes avec un temps de réponse moyen de 44 ms.

En réalisant de multiples tests on peut suivrel’évolution des performances quand on augmente la charge ( nombre d’utilisateurs concurrents).

En fonction de ce qui est acceptable pour les utilisateurs en termes de « temps de réponse », nous pouvons déterminer le nombre de transaction par seconde que peut accepter la nouvelle plateforme.
Dans notre exemple, si nous considérons qu’une latence de 100 ms est acceptable alors nous pouvons accepter jusqu’à 800 utilisateurs concurrents réalisant jusqu’à 700 transactions par seconde.
Au dela de 800 utilisateurs concurrents, mon « laptop » n’est plus en capacité de réaliser de test de montée en charge, il faudrait alors mettre en œuvre une architecture plus complexe comprenant plusieurs injecteurs, une console centrale etc.

Conclusion

Quelles conclusions tirer de ce test de montée en charge « à minima » ?

• Que la mise en œuvre de cette nouvelle plateforme ne présente pas de défaut ;
• Que cette nouvelle plateforme est bien dimensionnée par rapport aux besoins exprimés.

Quelles conclusions ne peut-on pas tirer de ce test de montée en charge « à minima » ?

• Que votre applicatif fonctionnera correctement sur cette nouvelle plateforme ;
• Que les performances obtenues avec les données « type » seront celle que vous obtiendrez avec vos données et votre application

Dans un scénario de migration, avec ce type de test de montée en charge nous aurons réduit fortement le risque de régression des performances sans toutefois le faire disparaitre complétement.
Si vous souhaitez plus d’informations sur « SwingBench », je vous renvoie au site web de son créateur : Dominique Gilles http://dominicgiles.com/swingbench.html