Les nouveaux besoins métiers imposent parfois une augmentation de la charge de votre IBM i, notamment les charges SQL et les charges http (appli web, Web Services …). Alors comment savoir si votre IBM i tiendra le choc face à cette augmentation et pouvons nous l’anticiper ?
La réponse est oui, nous pouvons l’anticiper avec la réalisation de tests de montée en charge. Pour cela, nous utiliserons un « stresseur » nommé Apache JMETER, disponible en téléchargement ici : https://jmeter.apache.org/ . C’est une application Open Source, en Java, permettant de tester et de mesurer les performances de vos serveurs : Web – http, HTTPS (Java, NodeJs, PHP, …) ; Web Services SOAP / REST ; FTP ; DB2 via JDBC ; LDAP …
Dans cet article, nous présentons deux configurations différentes :
- Un test de montée en charge d’une application PHP sur IBM i
- Un test de montée en charge d’une requête SQL sur IBM i
Une fois Apache Jmeter téléchargé et dézippé, lancez apache-jmeter-5.6.2/bin/ApacheJMeter.jar
Tester une application HTTP
Que ce soit une application web node.js, php ou un web service avec IWS, nous pouvons réaliser un test de montée en charge à l’aide du test suivant.
Commencer par ajouter un Groupe d’unités dans le plan de test :
Puis définissez votre test de montée en charge (nombre de requêtes, durée du test …).
Dans l’exemple ci-dessus, nous allons lancer un test de 50 requêtes en 0,5 s. A vous de faire évoluer vos tests afin de déterminer un point de rupture.
Ajoutez ensuite une requête HTTP
Et configurez la requête http à tester (protocole, nom ou adresse IP, port, méthode http, le path, les paramètres, la request body …).
En cas d’authentification, il est possible d’ajouter un élément « Gestionnaire d’autorisation HTTP».
Enfin, vous pouvez ajouter des éléments pour analyser les résultats du test comme un tableau de résultats (il en existe bien d’autres).
Votre test est prêt à être joué ! Appuyez sur le triangle vert pour le lancer et positionnez vous sur le tableau de résultats pour voir apparaitre les résultats qui arrivent en temps réel (1 ligne = 1 requête http avec son temps de réponse et son status code http).
Tester la database DB2
Au travers de la database, nous pouvons réaliser de plus en plus d’actions sur l’IBM i : requêtes DB2, interactions avec le système, appels de programmes … Le test suivant permet de mesurer la résistance de votre programme ou de votre base de données face à un pic d’activité.
Les principes restent les mêmes que pour le test précédent.
Première étape, ajout d’un groupe d’unités :
Puis ajout d’une configuration JDBC
Dans la configuration, il faudra indiquer :
- Un nom de liaison qui sera à réutiliser dans l’élément requête JDBC
- Une requête de validation dans la liste (exemple SELECT 1 from sysibm.sysdummy) car jt400 supporte JDBC 3.0 et les dernières versions de JDBC de JMETER implémente JDBC 4 ou supérieur.
- L’url de la base de données au format jdbc : jdbc:as400://bdd_name
- La classe du pilote JDBC : com.ibm.as400.access.AS400JDBCDriver
- Le profil/mot de passe de connexion
Il vous faudra télécharger le driver jt400 sur https://jt400.sourceforge.net/ et ajouter le fichier jt400.jar dans le dossier /lib/ de Apache Jmeter pour sa prise en compte.
Et ajouter votre requête JDBC :
Précisez le nom de liaison défini dans la configuration JDBC et votre requête SQL (passez par un CALL d’une procédure stockée pour appeler votre programme).
Puis ajouter un récepteur type Tableau de résultats, lancer le test et observer les résultats :
Conclusion
Et vous, quelle est la charge maximale que votre serveur peut supporter ? A vous de jouer !
gdumas@cfd-innovation.fr
06 07 52 54 16 
